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Sammanfattning 


Syftet med denna uppsats har varit att pröva en kombination av fyra olika metoder för att 
utvärdera ett IT-system. Metoderna som kombinerades var: processbaserad utvärdering, 
kriterie- och målbaserad utvärdering av systemet i användning samt kostnad - nytto - analys. 
Som underlag för min undersökning har jag använt mig av en fallstudie. För att utvärdera 
respektive metod har jag använt ramverket NIMS AD (Normative Information Model-based 
Systems Analys och Design) som är utvecklat utifrån erfarenheter av problemlösning inom 
aktionsforskning, industrin och konsultuppdrag. Ramverket kan användas för att utvärdera 
olika typer av utvecklingsmetoder och bygger på fyra väsentliga beståndsdelar (metodens 
kontext, användare, metoden samt utvärdering av dessa). För att en utvärdering ska bli 
effektiv bör den vara bra strukturerad och därför har jag valt Ramverkets tre element 
”problemsituationen”, problemlösningsprocessen och problemlösningen som grundval för 
utvärderingen och i dessa steg utvärderas före åtgärdandet, under och efter åtgärdandet. 
Resultatet av utvärderingen redovisas och jag beskriver utförligt hur det har varit att arbeta 
med metoderna. 

Det kan av vissa praktiker uppfattas som onödigt att kombinera flera metoder, dels pga. 
tidsåtgång men även att vissa av metoderna fokuserar på användbarhet, vilket kan ses som 
oväsentligt i en utvärderings situation, eftersom de funktionella kraven har en högre status. En 
forskare däremot kan se fördelen med olika angreppssätt för att säkerställa utvärderingens 
resultat. 

Att använda kostnad - nytto - analys kan av en praktiker upplevas som svårt eftersom man 
måste förstå olika ekonomiska begrepp och se till hela verksamheten, men metoden påvisar 
svagheter och styrkor som en praktiker många gånger tar för givet. 

Resultatet av undersökningen visar den styrka det blir att kombinera olika metoder när en 
utvärdering ska göras av ett IT-system. Metoderna med sina olika angreppssätt gör resultatet 
mer säkert i form av överensstämmelser, bristande överensstämmelser och motsägelser, allt 
för att säkerställa utvärderingen. Min uppfattning är att jag i den givna situationen lyckades 
med god säkerhet identifiera de problem som respektive målgrupp upplevde, men även de 
fördelar som IT-systemet hade. 

Styrkan är just att metoderna har olika angreppssätt, vilket gör att kombinationen känns 
tillförlitlig. En annan styrka är att respektive värderingsresultat kan ställas mot de övriga och 
granskas. 
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Inledning 


1 Inledning 

I detta kapitel kommer jag att beskriva uppsatsens bakgrund, syfte, frågeställning, målgrupp 
avgränsningar, samt dess disposition. 

1.1 Bakgrund 

I dagens verksamheter är investeringar nödvändiga, så att företagen har det IT-stöd som 
gör det möjligt att producera den service och de tjänster de utger sig för att leverera. 
Andelen datorer per anställd i tjänstemannasektorn har ökat väsentligt, men utan att 
motsvarande produktivitetsökning har skett ett, fenomen som har kommit att benämnas 
”The Productivity Paradox”. IT-investeringar har sedan dess diskuteras och ifrågasatt 
deras nytta. Det har i senare studier kunnat påvisas att IT-investeringar lett till betydande 
produktivitetsökningar, vilket påvisas framför allt från företag som samtidigt gjort andra 
insatser, exempelvis anpassat organisationen. IT har med andra ord varit en möjliggörare 
för att skapa förändringar och förbättringar men det behövs också andra insatser. Ryktet 
säger att IT-investeringar är ”svåra”, men de skiljer sig inte nämnvärt, från andra 
investeringar där man inför komplexa hjälpmedel (Ottersten & Balic, 2004). 


”När massafabriken skall köpa en ny massakokare räknar man noga på investeringen. 
Den nya massakokaren har betydligt större effekt, men skulle också skapa nya 
kostnader i from av extra personal, eftersom processen måste övervakas bättre. Detta 
skulle kräva ett bättre och säkrare flöde av råvaror. Trots anpassningar i 
organisationen och arbetssätt räknar man att nettonyttan skulle bli positiv” (Ottersten 
& Balic, 2004, s. 15). 

När industrin investerar i en maskin som massakokaren ovan, så har man en god insikt i 
hur den ska anpassas till arbetssättet och organisationen och få verksamheten att fungera 
så den ska ge den förväntade effekt som behövdes. Om en jämförelse samma liknelse 
görs med ett standardsystem som ska implementeras i en verksamhet så görs sällan 
analysen av hur detta nya system påverkar arbetssätt eller vad som kan behöva anpassas. 

I samband med vid IT-investeringar - oavsett om man ska bygga nytt, bygga ramverk 
eller komponenter, eller köpa ny standardprogramvara - gäller det att analysera hur 
produkten ska fungera i sitt sammanhang, men det görs ofta betydligt ytterligare än vad 
som görs för andra större investeringar (Ibid.). 

”När massakokaren var driftsätt höll fabrikschefen mycket noga kontroll på 
driftsstörningar, driftstid och effekt. Trots vissa inkörningsproblem - som man hade 
räknat med i kalkylen - så kunde han rapportera förväntad produktivitet och 
driftssäkerhet redan efter tre veckor” (Ottersten & Balic, 2004, s. 15). 

Här ses en betydelsefull skillnad mellan IT-investeringar och andra investeringar: För IT- 
investeringar görs sällan uppföljning av hur väl de fungerar i användning, medan man 
oftast följer upp andra investeringar (Ibid.). 
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Bristande kvalitetssäkring 

Gulliksen & Göransson, (2002) menar att historiskt sett har IT-utveckling varit en 
ingenjörsmässig aktivitet, baserad på systemteoretiskt och reduktioniskt tänkande. Detta 
synsätt innebär att verkligheten bryts ner till mindre delar som är överblickbara. Det här 
är ett bra sätt att utveckla på om alla påverkande parametrar är helt kända. ”Problemet” 
med IT-produkter är att de används av människor i komplexa sammanhang, där många 
påverkande parametrar är helt okända, okvantifierade eller osäkra. IT-produkter är inte 
tekniska system som fungerar i ett sammanhang - IT-produkter är verktyg eller medel för 
människor och verksamheter att åstadkomma något. 

Några bra metoder att kvalitetssäkra dagens systemutvecklingsmetoder ur ett 
effektperspektiv finns inte. Kvalitetssäkring handlar idag främst om att verifiera 
lösningarna och funktionerna mot en kravbild, en funktionsspecifikation eller ett 
användningsfall. Detta görs genom att kvalitetssäkra kod och modeller och genom att 
testa mot de specifikationer som tagits fram. Kvalitetssäkringen bygger åter på ett 
antagande att specifikationerna säkerställer att den förväntade effekten kommer att 
uppstå. Att IT-produkter är svåra att använda är därför inte helt ovanligt, trots att de 
innehåller alla specificerade funktioner och egenskaper. Hade målet istället varit att 
validera att IT-produkten skapar de förväntade effekterna blir det nödvändigt att styra 
mot hög användningskvalitet. 

Det finns många metoder som ska säkerställa IT-produktens användningskvalitet. De har 
tillkommit som en reaktion på 1970- och 80-talets sätt att utveckla IT-produkter som inte 
baseras på användarnas reella behov. Under senare år har också omfattande insatser 
gjorts för att finna standarder som föreskriver vilka aktiviteter som behöver utföras för att 
säkerställa god användningskvalitet. Men trots dessa banbrytande och viktiga insatser 
saknar många utvecklingsmetoder de mest basala kvalitetssäkringsåtgärder (Gulliksen & 
Göransson, 2002). 

• Målgruppernas behov, attityder och värderingar är en oerhört viktig del i kravbilden 
och måste därför samlas in, analyseras och värderas. Det räcker inte med att intervjua 
ett antal framtida användare. En systematisk insats innebär att först formulera vilka 
målgrupperna är, ta reda på deras uttalade och outtalade behov och sedan att prioritera 
dessa. Mål grupps analys borde vara en förutsättning för all kravhantering. Istället 
godkänner de flesta utvecklingsmetoder krav som är utarbetade på arbetsplatsmöten. 

• Produktens utformning ska baseras på förväntad verksamhetsnytta och nytta för 
användaren, användningssituation och de gällande standarderna. Det bör även finnas 
någon som ansvarar för att användargränssnittet är utformat på bästa sätt, en 
interaktionsdesigner. 

• Produkter som ska användas av människor måste utvärderas i verklig användning för 
att man ska kunna avgöra deras användningskvalitet, vilket innebär att om produkten 
inte fungerar som avsett då den används, så har den inte god kvalitet. En strukturerad 
metod som användningstest måste användas för att ta reda på vad som fungerar i 
användningssituationen, vad som inte fungerar och varför. Användningstest kan göras 
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mycket tidigt i ett IT-projekt. De är extremt effektiva och ändå föreskriver inte 
befintliga projektstyrnings - och utvecklingsmetoder att de används (Ibid.). 

Om det nu finns bristande kvalitetssäkring i ett systemutvecklingsprojekt, som Gul liksen 
& Göransson, (2002) påstår, hur väl överensstämmer det då med att en leverantör påstår 
att deras IT-system är det perfekta verktyget som verkligen kan effektivisera och lösa en 
verksamhets alla tänkbara problem? Eftersom IT - investeringarna ofta är dyrbara och 
inte alltid motsvarar beställarens önskemål, hur ska man då gå tillväga för att säkerställa 
att IT-systemet gör det som leverantören har utlovat att det ska göra? Det som kan göras 
är att utvärdera IT-systemet men hur ska man gå till väga? Och vilka metoder kan man 
använda? Detta vill jag försöka ta reda på. Jag vill använda metoder som tillsammans ger 
en helhetsutvärdering, och då menar jag metoder som utvärderar IT-systemets processer, 
funktioner och interface. Dessutom vill jag få in nytto- och kostnads- effekter då jag 
anser att det är viktiga aspekter när det gäller utvärdering. Ekonomiska aspekter som 
kostnads - nytto - effekter är synpunkter som alltid kommer utgör de tyngsta argumenten 
för eller emot ett IT-system. 


1.2 Syfte 

Syftet med denna uppsats är att pröva en kombination av fyra olika metoder för att 
utvärdera ett IT-system. Metoderna som kommer att kombineras är: processmodellering, 
mål- och kriteriebaserad utvärdering av systemet i användning samt kostnad - nytto - 
analys. Min ambition är att kunna bidra med kunskap om hur man utvärderar ett IT- 
system med en kombination av metoder. Jag kommer även att reflektera över eventuella 
för- och nackdelar med varje metod och eventuella för- och nackdelar med att kombinera 
dessa metoder. Som empirisk grund till denna utvärdering tjänar ett branschsystem som 
implementerades 2005. 


1.3 Frågeställning 

För att uppfylla mitt syfte vill jag försöka besvara följande frågor utifrån utvärderingen 
på just detta branschsystem: 

1 Vilka problem och styrkor finns med respektive metod? 

2 Vilka problem och styrkor finns med att kombinera dessa fyra metoder? 

1.4 Målgrupp 

Denna uppsats vänder sig främst till studenter som studerar 

Informatik/Informationssystem samt studenter vid Systemvetenskapliga programmet. 
Ytterligare en målgrupp är min uppdragsgivare samt övriga personer som har intresse av 
att studera hur man kan genomföra en utvärdering av ett IT-system. 
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1.5 Avgränsningar 

Utvärderingen kommer endast att göras på de funktioner som IT-systemet innehar, vilket 
innebär att integrationen mot andra system inte kommer att utvärderas. 


1.6 Disposition 

Uppsatsens disposition ser ut som följer: 

1. Inledning Här presenteras, bakgrund, syfte, frågeställningar, avgränsningar, 
målgrupp samt uppsatsens disposition. Detta för att sätta in läsaren i uppkomsten 
av uppsatsen, dess syfte samt nödvändig information för fortsatt läsning. 

2. Forskningsmetod Här presenteras på vilket sätt författaren har genomfört studien. 
Här styrks det gjorda vetenskapliga metodvalet av tidigare gjord forskning och 
teori. 

3. Informationssystem och användbarhet Här presenteras den teori som har gjorts 
tidigare inom området för att stödja den analys och slutsats författarens har 
kommit fram till i sin utvärdering. 

4. Introduktion till problemlösningsprocessen Här presenteras de fyra steg som 
Jayaratna (1994) menar utgör de olika faserna i problemlösningsprocessen. 

5. Ramverk för utvärderingen I detta kapitel presenteras Jayaratnas ramverk för 
utvärderingen av de fyra metoderna. 

6. Beskrivning av de fyra utvärderingsmetoderna I detta kapitel presenteras de fyra 
olika utvärderingsmetoderna. Processmodellering, mål- och kriteriebaserad 
utvärdering samt kostnad - nytto - analys 

o 

7. Presentation av IT-system och Återförsäljaren Här presenteras kort IT-systemet 
som ska utvärderas men även leverantören av systemet och återförsäljaren som 
använder systemet. 

8. Utvärdering av IT-system Här presenteras begrepp, tillvägagångssättet och 
utvärdering av varje metod enligt ramverket. Utvärderingsresultatet presenteras 
och därefter genomförs en analys och diskussion om varje metods 
utvärderingsresultat. 

9. Slutsats Här presenteras de slutsatser författaren har kommit fram till. 

10. Avslutande reflektioner Här presenteras författarens egna reflektioner över resultat 
och arbete. 
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2 Forskningsmetod 

I följande kapitel kommer jag att beskriva mina vägval för utvärderingen. Dessutom 
presenteras de metoder som kommer att användas för datainsamling till respektive 
utvärderingsmetod. Även den kritik som kan riktas mot mina valda metoder presenteras. Jag 
redogör också för min egen erfarenhet samt introducerar det ramverk som ska ligga till grund 
för utvärderingen av mina valda utvärderingsmetoder. 


2.1 Två vetenskapliga förhållningssätt 

Vetenskapligt arbete kan i princip bedrivas utifrån två olika forskningsideal. Dessa är 
hermeneutik och positivism. En av positivismens huvudteser är att ta avstånd från all 
metafysisk spekulation, det vill säga allt som inte är iakttagbart och verkligt utan endast det 
som bör vara objekt för vetenskapen. Alla vetenskapliga utsagor måste verifieras med 
empiriska data. Vidare ska allt arbete bedrivas med samma metod, ”den enhetliga 
vetenskapliga metoden”. Målet är att söka orsak-verkan-samband och generaliserbara 
orsakssammanhang och åtskillnad måste göras mellan fakta och värderingar. Positivismens 
forskningsprocess kännetecknas av att verkligheten observeras och verkliga fakta insamlas. 
Med tillräckligt många fakta är det möjligt att se mönster och regelbundenheter i verkligheten. 
Detta kan leda fram till allmänna slutsatser (lagar). Genom allt fler fakta som insamlas kan 
allt fler större och allmänna slutsatser dras (Lundahl & Skärvad, 1999). 

Det hermeneutiska idealet kan sägas vara positivismens raka motsats. Forskning om 
mänskliga och sociala förhållanden kan leda fram till kunskap som är bunden i tid och rum. 
Det råder skillnad mellan fysiska och sociala fenomen och alla fenomen tolkas och tyds av 
människan. Att forska på sociala fenomen är att förstå betydelser. Målet blir att uttolka och 
förstå hur andra människor upplever sin situation och vad detta betyder för handlingar och 
beslut. Att studera någonting utifrån vad det verkligen är och genom att förstå det speciella 
sammanhang, i vilket det ingår och styrs, vem som gör tolkningen samt ur vilket perspektiv 
och vilket språk som används. Man kan inte alltid skilja mellan faktaomdömen och 
värdeomdömen. Forskaren kan med inlevelse och engagemang försöka tränga in i och deltaga 
i det fenomen som ska studeras. Att förmedla kunskaper som känslor kan inte nås genom sunt 
förnuft. Det kan vara omöjligt och inte önskvärt att bedriva helt opartisk forskning då syftet är 
att förstå, men också att åstadkomma förändring och studera vad som då sker. Personliga 
erfarenheter är ofta nödvändiga förutsättningar för att uppnå vetenskaplig kunskap (Lundahl 
& Skärvad, 1999). 

Mitt förhållningssätt är det hermeneutiska idealet för att beskriva och tolka samt att få en 
djupare förståelse för hur respondenterna upplever att systemet stödjer dem i deras 
arbetsuppgifter. 


2.2 Kvalitativt kontra kvantitativt angreppssätt 

Syftet med kvalitativa undersökningar är att skaffa en annan och djupare kunskap än den 
fragmentiserande kunskap som ofta fås när vi använder kvantitativa metoder. Ambitionen är 
att försöka förstå och värdera helheten (Patel & Davidson, 1994). Och att försöka överskrida 
det subjekt-objekt-förhållande som utgör naturvetenskapen. Detta uppnår man genom att 
försöka sätta sig in i den undersöktes situation och se världen utifrån dennes perspektiv. Man 
försöker på så sätt se det fenomen som studeras inifrån. Utifrån denna utgångspunkt försöker 
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man skapa en djupare och mer fullständig uppfattning av den företeelse man studerar. 
Övertygelsen om att det inre perspektivet man studerar är det enda möjliga eller det enda 
vetenskapliga perspektivet. Man måste hela tiden kunna växla mellan ett sådant inre och yttre 
perspektiv - mellan att förstå och att förklara ett fenomen (Holme & Solvang, 1995). 

Vid kvalitativ forskning använder man sig inte av standardiserade frågeformulär. Detta för att 
man inte vill ha en för stor styrning från forskarens sida. Man vill tvärtom att de synpunkter 
som kommer fram är ett resultat av undersökningens respondenters egna uppfattningar. 

Därför bör respondentema i största möjliga utsträckning själva få styra utvecklingen av 
intervjuerna. Självklart har forskaren i förväg en uppfattning om vilka faktorer som är viktiga 
och skrivit ner dessa i en manual/handledning för intervjuerna. Men dessa behöver inte följas 
till punkt och pricka. Men intervjuerna måste täcka de områden som handledningen 
innehåller. I intervjusituationen dyker det ofta upp andra idéer eller uppfattningar som 
fördjupar eller ersätter de punkter som man hade innan i sin intervjumanual. Allt detta måste 
tas hänsyn till under intervjuns gång (Holme & Solvang, 1995). 

Den kvantitativa forskning beskrivs ofta av dess praktiker som att den har en logisk struktur, 
där teorin bestämmer vilka problem och frågeställningar forskaren ska ta sig an och att dessa 
formuleras som hypoteser som härletts utifrån generella teorier. Dessa hypoteser förmodas 
alltid anta formen av förväntningar om kausala samband mellan de begrepp som utgör 
beståndsdelarna i hypotesen. Begreppen kan ha uppfattats som abstrakta. Inom 
samhällsvetenskapen har man ansett det viktigt att definiera dem operationellt för att på så sätt 
kunna mäta hur de förändras och vilka samband som finns mellan dem. När informationen väl 
samlats in, analyseras den utifrån syftet att verifieras eller förkastas. En hypotes är det 
kausalsamband som hypotesen specificerade. Resultatet får sedan kopplas tillbaka till och 
införlivas i den teori som har varit utgångspunkten för forskningen. Den kvantitativa 
forskningen är mer inriktad på att ständigt visa att resultatet från en viss undersökning kan 
generaliseras till att gälla även andra situationer och andra personer än dem som studeras 
(Bryman, 1997). 

Den kvantitativt inriktade forskaren förmedlar en bild att den sociala verklighet som statisk, 
eftersom de har tendensen att förbise den betydelse och funktion som förändring har i ett 
socialt liv. Det finns en tendens att betrakta den sociala verkligheten som något yttre och 
tvingande i förhållande till aktörerna. Detta kan bero på deras preferens att behandla den 
sociala ordningen som om den var av samma art som de objekt som naturvetare studerar. 
Informationen som kommer från kvantitativa studier beskrivs ofta med ord som hård, strikt, 
rigorös och reliabel. Dessa adjektiv antyder att kvantitativa data rymmer en hög grad av 
precision, att de samlats in på ett systematiskt sätt och att det är lätt för andra forskare att 
kontrollera både informationen och resultaten. Dessa positiva egenskaper anses innebära att 
kvantitativa data är mer övertygande (Ibid.). 

Jag har valt det kvalitativa perspektivet som enligt min mening är avgörande för vilka 
metoder och tekniker som är lämpligast för att samla in och analysera den information som 
krävs. Eftersom kvalitativa undersökningar fokuserar på innebörd och sammanhang, som 
kräver ett datainsamlingsinstrument som är känsligt för mening och betydelse, både när man 
samlar in och analyserar information menar Merriam (1994). Många antar att en kvalitativ 
forskning måste vara helt sifferfri. Och menar att det inte är bra att vaska fram tal, och 
verkligen inte alls bra att sedan behandla talen statistiskt. Detta är bara antagande svepskäl 
menar Ely (1993). 
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2.3 Observation 

Intervjuer är en primär informationskälla under en fallundersökning. Detsamma gäller för 
observationer. Att samla in information genom observation av olika företeelser brukar kallas 
deltagande information, vilket skiljer sig från intervjuerna på två olika sätt menar Merriam, 
(1994). Intervjun genomförs på en plats som passar syftet med intervjun. Man ska till exempel 
vara ostörda, medan en deltagande observation så att säga sker på plats, ute på fältet. För det 
andra utgör intervjudata en andrahandsredogörelse för något, medan en observation är en 
direkt erfarenhet menar Merriam (1994). Men normalt brukar man dock kombinera informella 
samtal/intervjuer med observationer. 

Repstad (1999) menar att de värdefulla med observationer ger forskaren direkt tillträde till 
socialt samspel och sociala processer som intervjuundersökningar och textanalyser ofta bara 
kan ge indirekt och andrahandskunskap om. Det sociala samspelet mellan människor i utbyte 
av ord och handlingar, betraktas av många som det mest centrala temat i sociologin. Är den 
sociala relationen en viktig del av frågeställningen, är detta ett starkt argument att gå ut i 
verkligheten och observera det autentiska sociala samspelet som finns när detta äger rum. Det 
är svårt att i efterhand försöka rekonstruera olika samspel. Givetvis kan man föröka att 
rekonstruera, men de blir ofta bräckligt. 

Rollen som observatör kan utformas på olika sätt, den avgörande skillnaden är öppen eller 
dold observation. Med öppen observation menas undersökningar där deltagare vet om och har 
accepterat att man är observatör. Deltagarna är införstådda med att man gör en kartläggning 
av vissa faktorer som rör gruppens sätt att fungera. Dold observation står då för motsatsen, 
vilket kan delas in i två sätt. Den ena metoden innebär att man inte har någon direktkontakt 
med aktörerna. Och den andra är att man är deltagare i gruppen men att de andra inte vet om 
att man håller på med en undersökning (Holme & Solvang, 1995). 


2.3.1 Tyst kunskap 

Varje ögonblick tar vi emot en oerhört stor mängd omedvetna intryck som påverkar våra liv 
på alla plan. Ansiktsuttryck och kroppsspråk observeras samtidigt som vi noterar våra egna 
känslor, värderar dem och relaterar dem till allmänna normer för känslor och beteenden. Alla 
dessa intryck sammanfattas i vår tolkning av verkligheten och dessa tolkningar i sin tur gör 
det möjligt för oss att handla och fatta beslut varje sekund av våra dagliga liv. Känslomässiga 
och sociala färdigheter organiserar sig i en människokunskap som genomsyrar vårt vardagsliv 
som ett osynligt men totalt oundgängligt salt. Dessa förmågor tycks inte bygga på linjärt 
rationellt tänkande och logiska slutsatser. Tvärtom förefaller det som om vi samlar in otaliga 
intryck simultant, integrerar dem i helheten av mönster och jämför dem med våra tidigare 
erfarenheter vilket baseras på en fond av praktiska kunskaper. Men vi är inte medvetna om 
när vi använder oss av denna kunskap och vi minns inte hur den ackumuleras. Om vi söker en 
förklaring till dessa fenomen konfronteras vi med ett kunskapsteoretiskt problem med rötter 
långt tillbaka i västvärldens filosofiska tradition och som har aktualiserats under de senaste 
decenniernas försök att med hjälp av datorns hjälp konstruera en allmänintelligens som liknar 
människans. Inom både filosofin och forskningen av artificiell intelligens finns det två 
grundläggande uppfattningar om hur vår vardagskunskap och vår praktiska färdighet uppstår. 
Den ena uppfattningen är att det sker genom logiska slutsatser utifrån vissa bestämda regler 
och den andra att det sker via erfarenheter och på ett intuitivt och icke-analystsikt sätt 
(Vedfelt, 2000). 
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Den engelske filosofen Michael Polanyi myntade begreppet tacit knowledge för den tysta 
kunskapen som vi inte kan reflektera över eller ge uttryck för i ord och som vi kanske aldrig 
blir medvetna om att vi har. Enligt Polanyi är denna tysta kunskap, den grundläggande 
kunskapen, själva grundförutsättningen och basen för all kunskap. Den bygger inte på regler 
och är första hand förankrad i kroppen. I den praktiska kunskapen möter vi samma fenomen. 
När vi använder en hammare eller något annat verktyg lägger vi på samma sätt inte märke till 
hammarskaftet i vår hand. Och när vi t.ex. läser en text är bokstäver, ord och grammatik, tyst 
kunskap som vi inte noterar eftersom vår uppmärksamhet är helt fokuserad på textens innehåll 
och innebörd. Mycket av det vi lär oss sjunker ner i det omedvetna och breder plats för nya 
intryck. En erfaren sekreterare kan skriva rent ett utkast samtidigt som hon/han talar i telefon 
med en kollega. Dataexpertens fingrar vet var tangenterna med de olika bokstäverna finns på 
tangentbordet men det är inte säkert att han skulle kunna rita ett diagram över de tangenter 
han använder på sitt tangentbord (Vedfelt, 2000). 


2.4 Datainsamlingsmetoder 

Det finns ett flertal grundläggande vetenskapliga tillvägagångssätt att välja mellan, vilka vart 
och ett på sitt sätt belyser något hos den företeelse som ska studeras. Den viktigaste frågan är i 
grunden ställd till vad forskaren är ute efter. Fallstudier är partikularistiska, deskriptiva, 
heuristiska och förlitar sig i hög grad till induktiva resonemang när man hanterar 
mångfasetterande informationskällor. Fallstudie kan utgöra ett viktigt tillvägagångssätt när 
utvärderingsresultat är direkt avgörande för framtiden för en specifik företeelse och då det inte 
finns några användbara grunder för att avgöra om en handling varit framgångsrikt eller inte 
menar Merriam (1994). En fallundersökning kan även vara lämplig när den information man 
fått från deltagarna inte kan bedömas utifrån sanningsvärden men väl utifrån trovärdigheten. 
Syftet med en fallundersökning är i själva verket inte att komma fram till den ”korrekta” eller 
”sanna” tolkningen av de fakta man har tillgång till utan snarare att undanröja felaktiga 
slutsatser så man till slut har fått fram den bästa och mest övertygande tolkningen. 

Att samla information via intervjuer innebär att först avgöra vem som ska intervjuas. När det 
gäller kvalitativa fallstudier är detta beroende på vad forskaren vill ha reda på och vem det är 
som avgör att den eller den andra informationen är önskevärd. Urval av respondenter på 
grundval av hur mycket de kan bidra med till forskarens förståelse av den företeelse som 
studeras innebär att man måste göra teoretiska eller målinriktade urval av svarspersoner 
(Merriam, 1994). 

Det som skiljer de olika intervjutyperna åt är hur standardiserade de är. En hög 
standardisering är i regel frågeformulär där frågorna ställs i en viss ordning. Vid en 
ostandardiserad intervju kan man däremot välja både frågeformulering och frågornas 
ordningsföljd mer fritt. Den sistnämnda innebär att intervjuerna blir mer flexibla och 
situationsanpassade, men huvudsaken är att de frågor som ställs ger svar som täcker det 
informationsbehov man har (Lundahl & Skärvad, 1999). 

Etnografi är en forskningsmetod som utvecklats för att man ska kunna studera människans 
samhälle och kultur. På senare tid har termen etnografi använts synonymt med bland annat 
fältarbete, fallundersökningar och kvalitativ forskning. Etnografiska tekniker är de strategier 
som forskare använder sig av för att samla in information som rör den sociala miljön eller den 
situation som är föremål för undersökningen. De vanligaste teknikerna för datainsamling är 
intervjuer, källanalysbiografier, dagböcker samt deltagande observationer (Merriam, 1994). 
Etnografiska metoder har på senare tid växt fram som betydelsefulla analysverktyg bland 
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annat inom datorstött samarbete, CSCW (Computer supported cooperative work) (Gulliksen 
& Göransson, 2002). 

Karen Holzblatt & Hugh Beyer har definierat det de kallar för ”contextual design” baserat på 
det sätt som användarna vill utföra sina arbetsuppgifter. Metoden innebär framför allt att delar 
av den initiala utvecklingsverksamheten flyttar närmare användareorganisationerna och den 
verkliga målverksamheten. Huvuddragen i kontextbaserad är följande enligt Gulliksen & 
Göransson, 2002, s. 127): 

• Designern måste förstå användarnas arbetsplats och arbetsuppgifter. Utifrån den 
förståelsen kan en prototyp tas fram som sedan skall testas på den verkliga arbetsplatsen, 
alltså i den riktiga kontexten, inte i laboratorer etc. Givetvis finns det vissa arbetsplatser 
där det inte går att fullfölja fullt ut som exempelvis säkerhetskritiska situationer som 
flygplanspiloter 

• Kontextuella intervjuer innebär att man skall studera användaren (kunden) i 
användningssituationen för att verkligen förstå dennes behov och önskemål samt 
inställningen till sitt arbete. Det gäller att få underliggande arbets strukturer synliggjord. 
För att få en djupare förståelse för arbetes individualitet och kunna dra generella slutsatser 
för olika typer av användare, väljs några väl utvalda individer för att studeras. Det räcker 
med 10-20 intervjuer som var och en varar ca 2-3 timmar. Därefter genomförs en 
arbetsmodellering med kon kr eta representationer över det arbete varje intervjuad 
användare utför. Konsolidering används sedan för att se vilka gemensamma strukturer 
som har upptäckts. 

Föra att identifiera krav och behov hos användare kan en rad av ovanstående metoder 
användas. Preece (2002) menar dock att det är viktigt att veta vad man letar efter. I 
kontextuella intervjuer är det även viktigt att få med relevanta designförslag när man 
förbereder en datainsamling, vilket sedan ska ligga till grund för argumenten för individernas 
perspektiv och bakgrund. Den kontextuella intervjun skiljer sig från etnografiska studien på 
flera sätt (Preece, 2002, s.299). 

• Den är mycket kortare än en typisk etnografisk studie. En kontextuell intervju varar i två 
till tre timmar, medan den etnografiska är mycket längre och antagligen pågår i flera 
månader. 

• En kontextuell intervju är mer intensiv och fokuserad, medan den etnografiska är mycket 
mer övergripande. 

• I intervjusituationen har intervjuaren ingen deltagande observatör, men frågar om 
arbetsuppgiften. Intervjuaren observerar och frågar om olika beteenden, men deltar inte. 

• I samband med den kontextuella intervjun är avsikten att designa ett nytt system, men vid 
den etnografiska tillämpningen har den ingen agenda att följa. 

Valet av en fallstudie lämpar sig även för att på ett grundläggande sätt erhålla primär data för 
denna undersökning. Dels för att fallstudier lämpar sig för att testa och utveckla teorier, och 
dels därför IT-systemen kommer att utvärderas mer ingående och ur flera dimensioner enligt 
Lundahl & Skärvad (1999). Enligt Repstad (1999) kan en fallstudie ofta användas vid kritiskt 
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granskande av existerande teorier samt en den korta tidsperiod som undersökningen ska göras 
på passar för en fallstudie. 

Mitt val är en kombination av icke-standardiserade och kontextuella intervjuer. För att fånga 
data som är mer övergripande än respondenternas arbetsuppgifter som t.ex. företagetsmål, 
visioner, kunduppfattning, etc. Den kontextuella intervjun vill jag använda för att fånga varje 
målgrupps arbetsuppgifter. De tilltänkta respondenterna har en oerhörd tyst kunskap som de 
inte är medvetna om och inte kan förmedla direkt i ett samtal, och därför bör man ta hjälp av 
observationer som kommer naturligt i en sådan intervju. Det ger en möjlighet att registrera ett 
beteende i stunden. Genom att observera respondenternas arbetssätt kan jag även ifrågasätta 
och få förklaringar till varför vissa moment utförs på just detta sätt. Jag ser det också som ett 
sätt att sätta att minimera risken att vi missförstår varandra i kommunikationen då vi kan tala 
olika branschspråk. Det även vara enklare för respondenten att visa istället för att förklara. I 
kapitel 8 i avsnitt 8.2.2 ger jag en utförlig beskrivning av mitt tillvägagångssätt med 
respektive metod. 
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2.5 Genomförande med ramverk 

Metoder är vägledningar för det praktiska arbetet med exempelvis systemutvecklingsmetoder 
och de innehåller riktlinjer eller föreskrifter (Goldkuhl, 1991). Andersson (1994) menar att en 
metod är en detaljerad beskrivning av hur man går till väga för att utföra en viss uppgift. 
Jayaratna (1994) menar att metoder påvisar en annan viktig aspekt, nämligen hur dessa 
handlingar ska utföras och varför de ska göras i en viss ordning. 

Och i denna kontext definierar Jayaratna metoder som: 

”An explicit way of structuring one’s thinking and actions. Methodologies contain models 
and reflect particular perspectives of “reality” based on their embedded philosophical 
paradigms. A methodology must show “whaf ’ steps to take, “how” they are to be performed 
and most importantly the reasons “why” the methodology user must follow steps and in the 
suggested order” (Jayaratna 1994, s.37). 

Ett sätt att strukturera metodbegrepp är att betrakta metod utifrån företeelserna synsätt, 
ramverk, metodkomponent och samarbets- och insamlingsformer (Goldkuhl, 1991). Se 
nedanstående figur. 



Figur 1, Förhållandet mellan metodkomponent, ramverk, synsätt och samarbetsformer (Goldkuhl, 1991) 

Varje utrednings situation är unik, och därför bör metoder uppfattas som en verktygslåda, där 
olika verktyg kommer att användas i olika utredningssituationer. Dessa verktyg kallas 
metodkomponenter. En metodkomponent består av tre integrerade delar nämligen arbetssätt 
(vilka frågor som bör ställas), notation (hur svaren på frågorna skall dokumenteras) och 
begrepp (olika fenomen som behandlas i metodkomponenten) (Lind, 2001). 

Metoder bör inte följas slaviskt. Den som använder en viss metod behöver vara medveten om 
vilka val som kan göras inom ramen för ett gott resultat vid metodtillämpning samt deras 
konsekvenser. Metoder ska hjälpa människor att tänka bättre, alltså få dem att inte sluta att 
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tänka. Metoder ska därför bygga på bra argument varför man bör bete sig på ett visst sätt. 
Dessa argument har sin grund i metodens bakomliggande synsätt (Lind, 2001). 

Metoder innehåller bl.a. hur frågor ska ställas i en utredningssituation. Svaren på dessa frågor 
dokumenteras i anvisningar om, såsom textuella dokument, grafer, etc. Dokumenten 
struktureras på ett visst sätt för att visualisera särskilda aspekter av verksamheten. Metoder är 
till för att uppmärksamheten skall kunna riktas mot skilda aspekter av verksamheten, vilka 
finns uttryckta i synsättet bakom metoden, och därför ligger dokumenterade svar till grund för 
nya frågor (Lind, 2001). 

Ramverket NIMS AD (Normative Information Model-based Systems Analys och Design) är 
utvecklat utifrån erfarenheter av problemlösning inom aktionsforskning, industrin och 
konsultuppdrag. Ramverket kan användas för att utvärdera olika typer av utvecklingsmetoder 
och bygger på fyra väsentliga beståndsdelar (metodens kontext, användare, metoden samt 
utvärdering av dessa). NIMS AD utvecklades för att underlätta val av metoder eftersom det 
finns en stor mängd att välja emellan. Jayaratna menar att det finns en ovilja att avslöja 
brister, svagheter och olämpliga användningsområden för en metod. Därför behöver 
potentiella metodanvändare ett oberoende stöd som kan hjälpa dem att utvädra och finna den 
relevanta metoden för problemsituationen säger Jayaratna, (1994). 

Ramverket ska användas som en lins genom vilket utövaren kan studera begrepp, tekniker och 
metoder igenom. Modellen ska alltså utreda, kategorisera och utvärdera och den utgår från tre 
syften: 

• Det första syftet innebär att den ska hjälpa oss att förstå problemlösningsprocessen 
generellt i olika omgivningar. 

• Det andra syftet ska hjälpa oss att utvärdera metoden före, under och efter 
tillämpningen. 

• Det tredje syftet ska hjälpa oss att dra slutsatser (Ibid.). 



Problem-solving process 


Figur 2, Utvärdering före, under och efter, fritt tolkat efter Jayaratna (1994) 
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Jag anser att ramverket NIMS AD är den metod som bäst lämpar sig för att utvärdera mina 
valda metoder med, även om jag inte använder ramverket fullt ut. Ramverket fokuserar på 
problemsituationen (metodologins kontext), den avsedda problemlösningen (mytologins 
användare) och på problemlösningsprocessen (metodologin), och till sist utvärderads de tre 
ovanstående stegen, se figur 2. Ramverkets tillvägagångssätt presenteras i kapitel 6 och en 
introduktion till problemlösningsprocessen görs dessförinnan i kapitel 4. 
Genomförandeaspekter redovisas i inledningen till respektive metoder 8.2 -8.6. 

För att pröva min kombination av metoder valde jag att göra en fallstudie ute hos den 
återförsäljare som 2005 fick ett nytt branschsystem implementerat. I kapitel 3 ges en kort 
presentation av återförsäljaren, IT - systemet och systemleverantören. Att valet föll på just 
denna nyssnämnda återförsäljare beror på att de är en av de större återförsäljarna och ligger 
geografiskt närmast. IT - systemet och dess berörda målgrupper valdes genom samtal med 
implementerings- och ekonomiansvarige. Eftersom jag inte har obegränsat med tid var - jag 
tvingad till att inhämta all information på en och samma gång. Givetvis kunde 
kompletteringar göras via e-post och telefon. 


2.6 Sekretess 

Efter önskemål från Systemleverantören kommer jag inte att nämna företagets namn eller 
systemets. Dessa kommer att benämnas som System X och Systemleverantör X. Vidare 
kommer återförsäljaren och de intervjuade att anonymiseras. I en vetenskaplig rapport måste 
dessa önskemål visas vederbörligen hänsyn för att trovärdighet skall kunna uppnås på ett 
värdigt sätt. 


2.7 Metodkritik 

I kvalitativa fallstudier är intervjuer den huvudsakliga källan för att få fram de kvalitativa data 
som behövs för att skapa en förståelse av det man studerar. Det innebär då att det begränsas 
till forskarens sensibilitet och integritet. Om en intervju ska bli framgångsrik eller ej påverkas 
av samspelet mellan intervjuaren och respondenten. Detta samspel menar Merriam (1994) är i 
hög grad beroende av undersökarens förhållningssätt och förmåga att ställa frågor. Intervjuer 
har i likhet med andra metoder för datainsamling både starka och svaga sidor. När man utifrån 
resultatets giltighet jämför det med andra metoder, visar sig intervjuer (oavsett deras 
struktureringsgrad) vara ett bra instrument för insamling. Subjektivitet och komplexitet är två 
inneboende faktorer i det möte varje intervju innebär. Därför är det viktigt att 
intervjuprocessen, som är en social företeelse, analyseras och reflekteras. Även om det är 
omöjligt att undvika den mänskliga faktorn i intervjusituationen. Intervjuer är en primär 
informationskälla under en undersökning och det samma gäller för observationer. De som 
kritiserar deltagande observation som en teknik för datainsamling pekar på människans 
mycket subjektiva och därför otillförlitliga perception. Men som observatör kan man lägga 
märke till saker och ting som blivit en rutin för deltagarna själva, vilket kan leda till en större 
förståelse av hela sammanhanget menar Merriam (1994). Inom HCI (Human-Computer- 
Interaktion) är det vida känt att även om användare utan problem utför komplicerade uppgifter 
så kan de inte beskriva hur de genomför dem och detta brukar kallas tyst kunskap 1 . Utgår man 
bara ifrån vad användarna uttrycker muntligt så missar man sådant som för dem är självklart 
och sådana detaljer som de aldrig funderat över (Ottersten & Berndtsson, 2002). 


1 Michael Polanyi, The Tacit Dimension, Routledge & Kegan Paul 1996 
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Forskningsmetod 


Fallstudier ska ses som ett förlopp för att nå djupare förståelse för det man studerar menar 
Lundahl & Skärvad (1999). Nu hade jag inte denna tidsrymd utan den information som 
behövdes insamlades under två dagar. 

Mitt val av återförsäljare beror på att de ligger närmast geografiskt, men även att denna 
återförsäljare är störst vilket innebär att de har fler användare. Urvalet av respondenter styrdes 
i första hand av arbetsuppgifterna och om de utfördes i den del av IT-systemet som 
utvärderades. 

Det finns en risk i att jag varit ensam att utvärdera och inte haft någon att diskutera och 
analysera min tolkning med. Jag hoppas dock att ramverket NIMS AD ska kunna stödja mig 
och därigenom generera andra vinklar och aspekter på utvärderingen. Bell (2001) menar att 
det alltid finns risk för en viss skevhet när det bara är en person som intervjuar. Men jag 
hoppas att ramverket NIMS AD ska göra mig medveten om det men även att jag redovisar min 
förförståelse för det går inte att vara hundraprocentigt objektiv. Det finns även en stark vilja 
bland dem som intervjuas att vara till lags som brukar kallas respons- eller intervjueffekter. 
Mitt val att banda alla intervjuer för att sedan analysera dessa utan att transkribera dem kan 
kritiseras med att det kan vara svårt att överblicka alla data. Metoden kan bli tungrodd med att 
jämföra olika intervjuer. Men enligt Repstad (1999) & Bell (2001) är det många fördelar som 
man får med, så som olika tonfall och stämningar som man skulle missa vid textanalys. En 
annan fördel är att det sparar tid. 

Det kan ses som en nackdel att jag i min c-uppsats genomförde en acceptansstudie på IT - 
systemet och med avseende på tolkningen av empirin är jag medveten om att det kan vara 
svårt att möta någon helt objektivt. Man bör verkligen klargöra sin förförståelse, då det inte 
går att lösgöra sig från sina eventuella förväntningar, åsikter, fördomar och värderingar. Men 
om jag enligt Wallén (1996) medvetandegör dem så långt jag kan och aktivt prövar mina 
tolkningar kan jag se om jag har påverkats av dem och därmed kan andra möjligheter till 
tolkningar sökas. 


2.8 Min erfarenhet av studieområdet 

Jag har under olika utbildningar kommit i kontakt med dessa utvärderingsmetoder men inte 
direkt som utvärderingverktyg för IT - system, utan som verksamhetsutveckling. 
Processmodellering har jag studerat som en metod för att ta fram en kravspecifikation över en 
verksamhetsprocess. I kursen för Utmärkelsen Svensk Kvalitetsutveckling (USK) granskas 
och ifrågasätts verksamhetens alla processer. USK metoden använde jag som en metod att 
jämföra Capabllity Maturity Model (CMM) emot på kursen programvarukvalitet. Metoderna 
mål- och kriteriebaserad utvärdering har jag studerat och använt på utvärdering av en 
servicedisk och ärendehanteringssystem på ett företag. En viss beräkning av kostnad - nytto - 
analys gjordes också. Min erfarenhet av ekonomiska beräkningar har jag främst från studier i 
ekonomistyrning och investeringskalkyler. 

Jag har under lång tid följt IT-utvecklingen då jag startade i branschen 1989 när många 
företag började ersätta skrivmaskinerna med persondatorer. Jag ser mig som en van användare 
och har erfarenhet av utveckling och utbildning från olika typer av IT-system, vilket gör att 
jag kan negligera saker som mindre vana datoranvändare reagerar på. Men min erfarenhet av 
att utbilda noviser till experter har givit mig en insikt om och ett kritiskt förhållningssätt mot 
min erfarenhet. 
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3. Informationssystem och användbarhet 

Här presenteras olika teoribaserade ståndpunkter om hur ett IT - systems funktioner bör vara 
utformade för att stödja verksamhetens mål, målgrupper och kunder. Dessutom presenteras 
olika synpunkter om användbarhet, IT - systems målgrupper men även hur dessa aspekter 
påverkar en verksamheten produktion. 


3.1 Om IT är svaret - vad är då frågan? 

Idag framställs ofta IT som den räddande faktorn för utveckling av en verksamhet. IT ses inte 
bara som ett effektiviserande och rationaliserande av det administrativa arbetet. Det innebär 
även möjligheter att utarbeta helt nya processer, delvis ny form av produktionsteknik. IT har 
förändrat grunderna för hur arbete kan organiseras. Men teori och verklighet skiljer sig dock 
ofta åt (Ljungberg & Larsson, 2001). 

Traditionellt sett har användandet av IT inte ifrågasatt den struktur den haft i uppdrag att 
utforma datorstöd för, och därför har resultatet ofta blivit att man ”asfalterat kostigama”. En 
grundregel för systemutveckling, mer allmänt sett är att man i den ordningen som har 
återgetts ska förenkla, integrera och automatisera. IT bör alltså inte användas för att 
automatisera någon typ av system, utan att man först har ifrågasatt den grundligt (Ljungberg 
& Larsson, 2001; Gunnarsson m.fl., 1999). 

IT-utvecklingen har åtminstone historiskt sett snarare varit teknikdriven än styrd av verkliga 
problem eller behov. Utrustningen utvecklades innan man egentligen visste vad den skulle 
användas till eller vilka behov som skulle tillfredsställas. Inträdet i IT-åldem påstås ha skett 
just vid den tidpunkt då möjligheterna för första gången översteg behovet. Efter denna 
tidpunkt har det inte längre varit självklart att större, fler och mer också betyder mycket bättre. 
Framgångsrika IT-investeringar antar att det faktiska behovet fastställs innan systemet skapas. 
Möjligheterna överensstämmer inte nödvändigtvis med behoven och alltför ofta relateras 
medvetet eller omedvetet behovet till möjligheterna. Vad är det faktiska behovet (Ljungberg & 
Larsson 2001)? 

Den absolut starkaste trenden under de senare åren bland både stora och små företag har varit 
införande av affärssystem (även s.k. ERP-system, Enterprise Resource Planning). ERP- 
systemens mål är att integrera informationen i hela företaget och eliminera de dyra och 
komplexa länkarna mellan olika äldre - och ofta många, kanske 100-tals - system med 
omfattande underhållsbehov. Ett begränsat ERP-system anses därför obetydligt bättre än de 
gamla system som de ska ersättas med. Ju större installationen är desto större kan framgången 
förväntas bli (Ibid.). 


3.2 Affärssystemet en trojansk häst? 

Ett affärssystem är i teorin tänkt att utgöra en ”mjukvaruspegel” av företagets viktigaste 
processer. För att undvika att man ”asfalterar kostigarna” kan och bör i vissa fall införandet av 
affärssystemet medföra väsentliga förändringar vad gäller strategi, processer, struktur och 
kultur. Det kan till och med finnas en länk till övergripande visioner och affärsidé, men denna 
typ av förändringar kommer ofta som en överraskning eller förbises helt (Ljungberg & 
Larsson, 2001). 
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Affärssystemen och de projekt med vilka de implementeras tenderar att utgöra en trojansk 
häst. Få tycks vara fullt medvetna om deras innehåll och resultat. Om ett affärssystem 
integreras och ska stödja en del i verksamheten utan att skapa hinder för en fortsatt 
verksamhetsutveckling är konsekvenserna otaliga och komplexa. I praktiken innebär det ofta 
att organisationen och arbetsprocesserna anpassas efter de möjligheter som systemet ger, 
alltså inte tvärtom. Detta medför att systemen riskerar att styra hur verksamheten ska bedrivs 
och har därför ibland betecknats som ”processer på burk” (Ibid.). 

En verksamhetsprocess utgör det system som ska förverkliga affärsidén. Det är processerna 
som skapar värde för kunderna. Processerna avgör vad som produceras, men också hur. I en 
tid när differentieringen knappast uppnås på grundval av eventuell fysisk produkt, är 
processerna ofta det enda som skiljer det ena företaget från de andra. Att bara införa processer 
slentrianmässigt, som en biprodukt av ett IT-projekt, kan visa sig ödesdigert. Införandet av 
affärssystem har följdriktigt beskrivits som ”the world’s largest experiment in business 
change” (Ibid.). 

Även mycket små installationer är investeringstunga. Omfattande installationsarbete riskerar 
dominera förändringens kontenta, såsom de borde ses; att utveckla verksamheten med IT som 
möjliggörare. Projekten har ofta redan på planeringsstadiet paybacktider som överstiger trolig 
teknisk och kommersiell livslängd, för större organisationer handlar detta om 
miljardinvesteringar. Ofta överskrids den uppskattande projekttiden vilket ytterligare skjuter 
de ekonomiska vinsterna in i framtiden. Många upplever att den stort sett aldrig tar slut. Eviga 
uppgraderingar av mjuk- och hårdvara fortsätter att förbruka resurser. Det som började som 
en projektorganisation för införandet, övergår i en permanent avdelning för underhåll och 
support. Uppdateringarna är lätta att sälja in. Varje programversion är full av buggar som 
måste elimineras i uppdateringen. De nya versionerna innehåller dock nya möjligheter vilket 
också innebär att ett antal nya buggar förs in. De investeringsbeslut som ligger till grund för 
ERP-installationen tycks ofta baseras mer på tro och framtidsvisioner än på fakta och kalkyler 
(Ibid.). 


3.3 Standardsystem ur verksamhetens synvinkel 

Det finns idag erfarenheter kring frågor och användningen av standardsystem i organisationer, 
men ändå sker en hel del upphandlingar av standardsystem enligt ad-hoc-mässiga strategier. 
Standardsystem införs mer eller mindre i kaotiska miljöer där det pågår för mycket samtidigt. 
Man väljer standardsystem mer på känn (med ”hjärta”) och inte utifrån sunt förnuft (med 
”hjärnan”). Några konsekvenser av detta kan bli( Nilsson, 2000, s.205): 

• Standardsystem underutnyttjas i, eller rent förstör, verksamheten. 

• Leverantör sberoendet ökar vilket leder till omfattande merarbete. 

• Ständiga anpassningar äger rum i såväl verksamheten som systemet. 

Förvånansvärt har väldigt få seriösa metoder utvecklats för anskaffningen och förvaltningen 
av standardsystem i organisationer. Hur ska jag som kund välja, anpassa, införa och förvalta 
standarsystem i min organisation? Kunden är ofta den svagare parten på markanden jämfört 
med leverantören som har en mer omfattande erfarenhet från ett stort antal installationer 
(Ibid.). 
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3.4 Standardsystem ur leverantörens synvinkel 

Under en två-års-period (1994-1996) genomfördes en omfattande branschstudie som underlag 
för att beskriva och analysera den svenska markanden för standardsystem. Den ger en bra 
lägesbild av branschen ur leverantörens synvinkel. Branschstudien koncentrerades till att 
omfatta den svenska markandens tillgängliga standardsystem från inhemska och utländska 
leverantörer (Nilsson, 2000). 

Resultatet som framkom blev på olika sätt att dela in leverantörer och deras produkter i olika 
grupper eller ”högar”. På så sätt ville man få inblick i hur kunderna bör välja från rätt grupp 
av leverantörer. Kortfattat beskrivs endast några intressanta observationer från branschstudien 
(Nilsson, 2000, s. 185 - 189): 

• Varierande systemkvalitet. De Standarsystem som var mer heltäckande innehåller två 
huvuddelar i from av ett administrativt stöd för ekonomistyrning respektive materialflöde 
i ett företag. Tonvikten kvalitetsmässigt har leverantören lagt på en av dessa huvuddelar 
och börjat utvecklat en ”excellent” del. Den andra delen har man senare försökt bygga på 
ett tillräckligt bra sätt. 

• Glömda kundgrupper. Medelstora företag kan ses som en glömd kundgrupp, men även 
tjänsteproducerande företag. Leverantören har antingen försökt skapa en god 
affärsrelation mot större företag eller lagt fokus på snabba och avgränsade försäljningar 
mot mindre företag. 

• Olika verksamhetsfilosofier. Här har olika filosofier och inställningar för hur 
standardsystem bör förhålla sig till verksamhetens arbetssätt påverkat leverantören. Ett 
”styrande” standardsystem innebär att kunden anammar leverantörens inbyggda 

verksamhetskoncept i systemet. Ett ”följande” standardsystem innebär att leverantören i 
systemet är öppen för olika uppläggningar eller verksamhets scenarios. 

• Systemets omfattning. Olika ambitionsnivåer har präglat utvecklingen av 
standardsystemet. Standardsystemet varierar i komplexitet alltifrån totalsystem till 
avgränsade nischsystem. Affärssystem kallas idag totalsystem eller mega-paket. 
Nischsystem kan vara fokuserade på applikation (t.ex. personalförsörjning), område (t.ex. 
hotellbokning), och lokalitet (t.ex. viss geografisk region). 

Standardsystem används idag som avancerade hjälpmedel för att kunna effektivisera 
affärsverksamheten inom företag och organisationer. Leverantören har utvecklat en 
standardiserad programvara som ska motsvara flera användare (kunders) verksamhetsbehov. 
En stor potential med standardsystem ligger i att beprövade erfarenheter och kunskaper finns 
inbyggda i systemet från tidigare installationer. Skalfördelar finns i och med att ett stort antal 
användare utnyttjar samma system. Idén är att fler organisationer ska använda systemet och 
man slipper uppfinna hjulet på nytt. Vilket innebär att tid, kostnader och ansträngningar 
fördelas på flera företag (Ibid.). 


3.5 Informationssystem 

Ett informationssystem kan bara förstås i förhållande till en verksamhet. Ett 
informationssystem har ingen egen meningen i sig och existerar bara för att tjäna sin 
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verksamhet. Insamling, bearbetning, lagring, överföring och presentation av information kan 
inte utföras på ett vettigt sätt om man inte känner till verksamheten, dess mål och uppgifter. 
Informationssystemet samlar in information både från verksamheten och dess omgivning och 
distribuerar informationen till verksamheten och dess omvärld (Jayaratna, 1994). 



Figur 3, Informationssystemet är en del av verksamheten (Andersson, 1994) 

I vår komplicerade värld i dag och med den hård konkurrens som råder mellan olika 
verksamheter, är det viktigt att informationssystemet är utformat på rätt sätt. En verksamhet 
med ett bra informationssystem skapar konkurrensfördelar (Ibid.). 

Jayaratna (1994) definierar informationssystemutvecklingsmetod så här: 

“a system for the most efficient and effective means of identifying the 
“real” needs of users, and developing information processing systems 
for satisfying these needs; ensuring that the resulting information 
processing system continues to satisfy changing user needs by the 
most efficient means of acquiring, storing, processing, disseminating 
and presenting information; by providing facilities and a learning 
environment for users and information systems specialists to improve 
the effectiveness of their decision models; and by supporting 
operational, control and strategic organisational objectives” (Jayaratna, 

1994, s.21). 


3.5.1 Informationsprocesser och användarfunktioner 

Det är inte överraskande att ett informationssystem har framkommet ur den praktiska 
tillämpningen och demonstrerar användningen i praktiken. Ett system vars huvudsakliga 
uppgift är att skaffa information för att stödja användarnas beslutstagande oavsett nivå i 
organisationen. Denna rollfunktion måste vara effektivt organiserad för att stödja användaren 
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med anskaffning, lagring och spridning av information för ett kontinuerligt beslutstagande 
(Jayaratna, 1994). 

Det behöver göras en definition om vad som menas med ett effektivt sätt att producera 
information. Effektivitet kan definieras som ett värde för kostnad/nytta av att producera 
information. Exempelvis, om en informationsprocess kan utföras lika effektivt och mot lägre 
kostnad, då sker en ökad effektivitet. Men många organisationer fortsätter med 
effektiviseringen av funktionerna vilket gör det oerhört dyrt istället (Ibid.). 

Det är viktigt att informationen överensstämmer med användarnas behov på ett kontinuerligt 
sätt. Det är just matchningen som bidrar till effektiviteten. Effektiviteten blir då måttet på hur 
anpassad och användbar den blir i förhållandet till målet. Exempelvis, en beslutsfattare måste 
ta ett strategiskt beslut om informationen, då kan bidra till detta, är informationen effektiv inte 
annars (Ibid.). 


3.5.2 Strategi och planering av funktioner 

Den strategiska rollen för informationssystem kan ses från två plan: Det första är att stödja 
organisationens gemensamma information för strategiska beslutstaganden. Administrativa 
informationssystemet ska fylla den rollen. För de andra ska informationssystemet ur den 
gemensamma informationen skapa underlag för strategiska beslut för att ta fram nya koncept 
för organisationen (Jayaratna, 1994). 

Distinktionen mellan strategiska informationssystem och andra typer av informationssystem 
kan beskrivas så här: ”Ett informationssystems strategi är att bidra till att en organisation kan 
förändra sina produkter eller sin service till sina kunder”. Ett strategiskt informationssystem 
kan inte införas utan vidare. Det krävs noggrann planering eftersom den påverkar 
organisationens kultur, status, arbetsfördelning, social kontext etc. Många företag ser inte och 
tar ingen hänsyn till att införande är en organisationsförändring. Det finns alltså kritiska 
faktorer som påverkar om systemet ska bli en framgång eller inte. Det behövs alltså 
kännedom innan införandet och en planering hur omläggningen ska göras. Det kan handla om 
hela organisationens arbetssätt och sådant ändras inte under ett par veckor (Ibid.). 


3.5.3 Utbildande och lärande funktioner 

Det här området brukar man inte ägna så mycket intresse för, men dessa funktioner är inte 
heller enkla att tillgodose. Att producera tillförlitlig information är en sak men att samtidigt 
bidra med lärandemöjligheter är en annan. Det inte bara lärandet av hur informationen ska 
användas utan också hur användarna kan utvärdera sin egen effektivitet på beslutstagandet av 
sina aktiviteter och handlanden. Det är viktigt att användaren kan påverka, godkänna och se 
nya möjligheter för användbarheten på funktionerna för informationsproducerandet. Det är 
också viktigt att det görs fortlöpande utvärdering och modifiering av modeller för 
beslutstagande när användarna verkar i en dynamisk omgivning. Denna brist på utvärdering 
saknas ofta och blev uppenbar i en studie som gjordes ute på ett distributionsföretag, hos en 
grupp controller som vars huvuduppgifter var handel med aktier och värdepapper. De hade 
nyligen fått ett nytt informationssystem implementerat i sin verksamhet. Den nya modulen 
som de skulle arbeta med fick de ingen utbildning på vilket medförde att de inte visste hur 
alla de nya funktionerna fungerade. Därför började de istället hämta information från en 
informell depå på nätet, för att kunna utföra sina arbetsuppgifter (Jayaratna, 1994). 
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Den nytta och möjligheter som den nya modulen kunde ha bidragit med för analys av aktier 
optioner, avancerade stimuleringar av cash flow, kundservice och marknadsandelar. Men hur 
skulle de få den informationen när ingen visade att den fanns. Det var inte heller någon 
utbildning som erbjöds för att lära sig modulen. Detta visar att den effekt som företaget 
investerat i för att öka den effektivitet mot konkurrenter inte utnyttjas, för att controllern inte 
visste att den fanns. Utan istället blir det en modul som utnyttjas minimalt med höga 
investeringskostnader och låg effektivitet (Ibid.). 

Det är orimligt att förvänta sig att användarna ska se alla möjligheter med ett nytt system. Det 
visar också hur viktigt det är att utveckla nära användarna för att få funktioner som är 
anpassade till deras behov. Utvecklare är inte experter på de arbetsuppgifter de ska utveckla 
för, det vet inte vilka beslut som kommer att tas på den information som systemet producera, 
det kan endast användarna göra. Därför bör användarna involveras innan beslut tas för vilken 
information som behövs eller inte. För att användare ska förstå och se möjligheterna av 
informationshanteringen bör utvecklingen alltid ske i nära samarbete (Ibid.). 

Utbildning och lärandet av funktioner bör vara en kontinuerlig utveckling för både 
användarna och utvecklarna. Informationssystemets definition skulle kunna utökas med 
följande: Ett system producerar information för sina användare, för att dessa ska ta effektiva 
beslut, men systemets effektivitet visar också prov på att utvecklarna ha förmedlat bra 
funktioner och aktivt lärande (Ibid.). 


3.5.4 Förstå IT-systemet och användarkaraktärer 

IT-system kan variera från att hantera enkla funktioner som grundläggande beräkningar till 
extremt komplexa funktioner som att övervaka och kontrollera kemiska processer. Ett IT- 
systems komplexitet beror på antalet komplexa funktioner som IT-systemet kan utföra. 
Mjukvaruföretag strävar efter att bygga in så många funktioner som möjligt för att mjukvaran 
ska var så användbar som möjligt. Men summan av kardemumman blir att ju mer funktioner 
desto svårare att designa ett interface som ska ge en god användarekvalitet. Om IT-produkten 
är komplex så kommer interfacet att ha ett antal av display, menyer, kontroller och många 
nivåer på interfacets funktionalitet. Denna trend med enorm funktionalitet är på frammarsch 
och benämns som "creeping features ”. Ett problem med ytterligare funktioner gör att 
interfacet blir ännu mer komplext och användarna ställs inför en ofantlig valmöjlighet. 
Exempelvis hade Microsoft Word 1992, 311 kommandon vilket nu är uppe i 1000 
kommandon. Ett fåtal användare kommer att finna några kommandon användbara, medan 
återstående bara komplicerar systemet (Wickens m.fl. 2004). 

Klyftan mellan användarnas behov och produktens efterfrågan beror helt på produktens 
utformning. IT-produkten är ofta en del av ett system som är sammanfogat med andra IT- 
produkter med komplexa utföranden som användaren känner igen. Som jämförelse kan tas att 
arbeta med en text i Word mot olikheten att arbeta i ett kalkylblad i Excel eller i en 
databashanterare. Det är majoriteten av användarbehovet som ska styra och inte den specifika 
IT-produkten, men likväl styr också organisationen och dess kultur utvecklingssituation av 
IT-produkten. Det är alltså en balansgång mellan användarens behov, IT-produktens 
funktionalitet och omgivningen som IT-produkten ska verka i. Komplexa IT-produkter kräver 
ett komplext interface med många funktioner vilket medför en viss utbildningstid för 
användaren. För designern av gränssnittet innebär detta att i varje fall hitta den korrekta 
balansgången mellan IT-produktens användningskvalitet och användarens ansträngning att 
lära sig IT-produkten. Det gäller alltså att hitta den optimala funktionaliteten för varje 
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användare som typ (1), den högfrekvente användaren som utför specifika arbetsuppgifter. (2) 
den tvingade och den mot villige användaren som använder systemet efter behag och (3) 
kunskapsnivån på användarna. Dessa kriterier är viktiga att ta del av när det gäller 
användarekvaliteten (Mayhew 1992; Wickens m.fl. 2004). 

Vissa IT-baserade arbetsuppgifter är t.ex. ordbehandling där användaren kan sitta ända upp 
till åtta timmar om dagen, dag efter dag. Andra arbetsuppgifter kräver att man sitter en eller 
två gånger om året och skriver. Därför är designen viktig när det gäller den högfrekvente 
användaren för den är villig att investera i mycket tid för att lära sig IT-produkten, vilket 
innebär att designen kan vara mer komplex med funktionaliteter. Men de vill ha kommandon 
som är lätta att komma ihåg och inte belastar minnet oavsett sammanhang. Detta gör att 
designen ska kan konstrueras på igenkännande och därigenom en minskad minnesbelastning. 
Det är också stor skillnaden mellan individer som använder ett system för att det vill, och de 
för att någon kräver det. Den ”villige” är användare som använder ett speciellt program 
tämligen frekvent men har inte en lika bred kunskap som en expert. Design förslag för den 
högfrekvente användaren eller den tvingade användaren, bör vara enkel att använda. Men hur 
som helst måste den vara att lätt att lära, lätt att komma ihåg, lätt att använda och ha första 
prioritet för den frekvente användaren oavsett grad (Mayhew 1992; Wickens m.fl. 2004). 

Slutligen måste man också kategorisera användarna från noviser till experter. Det finns tre 
klasser som är kategoriserande enligt följande (Wickens m.fl. 2004, s.37): 

• Novisanvändare: Individer som kan sin arbetsuppgift men inte har kunskap om IT- 
systemet. 

• Kännedom och periodiska användare: Individer som har kunskap om sin arbetsuppgift, 
men p.g.a. sporadiskt användande av IT-systemet har de svårt att komma ihåg hur de 
skulle gå till väga. 

• Expert med frekvent användning : Användare som hur djup kunskap om arbetsuppgiften och 
kan hantera, begära och fullborda mål för arbetsuppgiften. 

När det gäller designutförandet för novisen bör fokus ligga på lätt att använda, lätt att lära 
samt komma ihåg. Vokabulärerna är starkt begränsade uppgifter som är lätta att utföra och 
innebörden av felmeddelanden är lätta att förstå. IT-produkter som är byggda för 
förstagångsanvändare och kallas ”Walk up and use ”, är representativa produkter som checkin 
system vid flygplatser. Den dominerade teknologin som används för noviser är ikoner, 
menyer med korta skrivna instruktioner och ett grafiskt gränssnitt GUI (Graphical User 
Interface). GUI är en benämning av komponenter som visas på skärmens fönster, menyer, 
pekare, ikoner, etc. De grafiska bilderna genererar ett igenkännande hos användarna som 
villigare klickar på grupper av ikoner och menyer än skriver in textkommandon som belastar 
Långtidsminnet (LTM) ” knowledge in the heacC\ Grafiki ska igenkännanden hjälper individen 
att direkt se vad som ska göras, vilket inte alls belastar någon minneskapacitet, och därmed 
blir det bästa för novisen. Exempelvis ger GUI tydlig hjälp att flytta ett stycke text på ett 
dokument till ett annat dokument genom att de märker ut stycket och drar stycket till det 
andra dokumentet. Detta gör att igenkännandet är effektivare för novisen efter som minnet för 
igenkännande är mer pålitligt än att komma ihåg skrivna kommandon och ladda 
långtidsminnet (Ibid.). 
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Att reducera minnet för sporadiska (intermittenta) användare är speciellt kritiskt oavsett om de 
är experter eller inte. Dessa användare vet hur de ska utföra sina arbetsuppgifter effektivast 
och har god kännedom om IT-produkten och har förmågan att snabbt återkalla 
långtidsminnet. Att skriva in kommandon brukar tilldelas experter, särskilt om de är frekventa 
användare, vilket är snabbare samt ger en känsla av att ha kontroll över situationen. Men det 
är svårt att tillgodose den mångfald av användartyper som ska arbeta i ett interface. Ett sätt att 
lösa dessa aspekter är att man skapar flera sätt att utföra ett kommando på, som t.ex. 
snabbkommandon, menyer och muspekare. Individer som från början har använt grafiskt 
gränssnitt är inte benägna att börja skriva kommandon, trots att de har en lång erfarenhet och 
att det ger ett snabbare och effektivare arbetssätt (Ibid.). 

Aspekter som lätt att lära och lätt att komma ihåg är mindre viktigt för IT-system som ska 
användas av experter. Att designa en manöverpanel till ett kärnkraftverk, där styr 
informationsmängden interfacet, eftersom en stor mängd information och 
inmatningsmekanismer ska styra arbetsuppgiften. Detta medför att arbetsuppgiften är 
komplex, så att en hel del tid kommer att läggas på utbildningen av IT-systemet. Här bör 
prioriteringen hellre ligga på inga eller ”/å/<?/”, än att minska utbildningstiden, vilket ses som 
en självklarhet för att jobba snabbt och effektivt i denna miljö. Men generellt ska även detta 
interface stäva efter att maximera användarkvalitet som lätt att lära, effektivt, lätt att komma 
ihåg och ge tillfredsställelse att jobba med. Dessa kvalitetsegenskaper skiljer inte för någon av 
de nämnda användartyperna (Ibid.). 

Även av grupper som novis, sporadisk användare och expert visar en klar indikation om 
vilken design som bör användas, så är det ändå svårare än man tror. En del individer använder 
specifika delar av programfunktionema olika mycket, exempelvis en person som är expert på 
ritverktygen i MS Word men sporadiskt använder tabellfunktionerna och är helt novis på att 
använda e-postfunktionen. En sekreterare med 20 års erfarenhet att framställa dokument men 
är novis på att arbeta i en ordbehandlare. Detta visar att man måste vara oerhört vaksam när 
man delar in användare i dessa kategorier och inse att det faktiskt är mer sofistikerat än så 
(Ibid.). 


3.5.5 Användar- och uppgiftsanalys 

Närmare 50 % av programkoden i ett IT-system utgörs av användargränssnittet enligt Nielsen, 
(1993). Men motsvaras denna kod av 50 % av utvecklingsarbetet? Nej, åt gränssnittet ägnas 
sällan mycket tid. Oftast är det verksamhetsfunktioner och databasarbetet som är det som 
tilldelas allra mest resurser i form av bemanning och utvecklingsresurser. Men hur stor del av 
utvecklingsbudgeten ägnas åt användbarhetsrelaterat arbete? Ett snabbt överslag hos flera 
stora organisationer visar att andelen användbarhetsrelaterat arbete ofta inte uppgår till mer än 
en procent. 

Men en systemutvecklare är inte den typiske användaren av de system eller tillämpningar som 
hon/han utvecklar menar Gulliksen & Göransson, (2002). Om man inte lyckas förstå vi lk a 
uppgifter användaren utför eller hur de utför dem, kan man inte utveckla ett system eller 
produkt som möter användarens behov och förväntningar. Att förstå de tilltänkta användarna, 
deras uppgifter, användningsmiljö, organisation, etc. är en nyckel till hela 
utvecklingsprocessen. Man kan samla in högvis med data, analyser, köra stora tester, men om 
deltagarna inte är representativa eller om man inte lyckas förstå hur och varför uppgifterna 
utförs, vad har man då tjänat? Kunskap om användarna inkluderar även deras kunskapsnivå, 
utbildning och träning, användningsfrekvens, arbetsmiljö, arbetsuppgifter m.m. (Ibid.). 
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Det absolut bästa sättet att samla in kunskap om användarna är att mer eller mindre leva i 
deras arbetsmiljö. Detta ger nödvändiga och oersättliga insikter i arbetsförhållanden, 
användarkategorier och andra förutsättningar. Man måste alltså ut till användarnas arbetsplats 
för att lyckas fånga saker som inte går att fånga på annat sätt än med fysisk närvaro. Det är 
först då vi har möjligheten att se informella organisationsstrukturer, ta del av ”tyst kunskap”, 
etc. Resursåtgången och kostnaderna för analys av användarna kan variera stort, allt från det 
mycket enkla och billiga till det mer genomgripande och därmed kostsammare. Det kan också 
finnas tidigare gjorda analyser, branschorganisationer kan ha bakgrundsmaterial, etc. som 
man inte tänkt på och som kan komma till användning (Gulliksen & Göransson, 2002). 

Syftet med användar- och uppgiftsanalysema är att tillsammans med användarna ta reda på 
vilka uppgifter som utförs, vilka som utför dem, hur det utförs, hur nuvarande stödsystem 
fungerar och hur användarnas arbetssituation och informationsstöd kan förbättras (Ibid.). 

Användaranalysen skall ge svar på vilka användarkategorier som finns, för vilket ett IT- 
system skall utvecklas, samt vilka egenskaper de kategorierna har. Det är oerhört viktigt att ta 
hänsyn till de skillnader som finns mellan de olika kategorierna vid designen av det framtida 
IT-systemet. Användare för ett fiktivt kontor kan exempelvis vara Gulliksen & Göransson, 
2002, s.220): 

• Kontorschef 

• Handläggare av komplicerade ärenden 

• Handläggare av enkla ärenden 

• Kundmottagare 

Egenskaper som är viktiga för respektive användarkategori kan vara Gulliksen & Göransson, 
2002, s.220-221): 

• Erfarenheter hur uppgifterna skall lösas. Är det huvudsakligen nyanställda som har lite 
erfarenhet eller är det verksamhetserfarna med vana eller är det en kombination? Alla tre 
fallen ställer speciella krav på användargränssnittet. 

• Vilken utbildning har användarna - både akademisk och företagsanpassad sådan? Vilka 
språk används, är ett program där engelska termer förekommer ett problem? 

• Vilken datorvana har användarna? Hur stor är datorvanan och har de använt de senaste 
typerna av datorsystem, eller finns det ingen datorvana alls? 

• Hur mycket tid kommer att läggas på utbildning? I vilket sammanhang kommer 
datorstödet att användas och hur ofta? 

• I vilken miljö kommer systemet att finnas? Finns det användare med speciella fysiska 
hinder? 

o o 

• Alder och kön kan vara en påverkande faktor. 

Oavsett vilka metoder (observation, intervjuer, enkäter) man använder för att urskilja typer 
eller kategorier av användare med liknande bakgrund, förutsättningar, arbetsuppgifter och 
krav på användargränssnittet. Ska analysen resultera i exempelvis: användarprofiler, 
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designrekommendationer (kategorier) samt delar i ett underlag för en kravspecifikation 

(Ibid.). 

Det är viktigt att se skillnaden mellan utvecklare, verksamhetsexperter och användare. 
Utvecklare är präglade i sin roll som utvecklare och kan aldrig vara användare. 
Verksamhetsexperten är expert inom det område som IT-systemet man utvecklar för och det 
är viktigt att få fram kunskap om tillämpningsområdet. Likafullt måste de kompletteras med 
användare - de som i sitt dagliga arbeta skall jobba med systemet. Det är egentligen endast 
dessa användare som kan tala om hur bra man lyckats gör IT-systemet användbart (Gulliksen 
& Göransson, 2002). 


3.5.6 Minskad inlärningstid 

En kortare inlärningstid är mycket viktigt för en produkt som ska användas sällan eller där det 
ständigt tillkommer nya användare. Om produkten utformas så att den utgår från användarens 
förståelse av ämnesområdet och stödjer lärandeprocessen minskas inlärningstiden. Stödjande 
lärandeprocess är att använda bekanta begrepp för användaren, ge tydlig återkoppling och att 
produktens utformning och beteende följer ett tydligt mönster. En god idé kan vara att skapa 
speciella avsnitt med lärande som enda syfte. Dessa kan vara egna interaktiva 
utbildningsprodukter som används i anslutning till huvudprodukten eller integrerade i 
hjälpfunktionerna (Ottersten & Bemdtsson, 2002; Meyhew & Randolph, 2005). 


3.5.7 Övertro på utbildning 

Det är viktigt att åstadkomma så effektiv användning som möjligt. Detta fås framförallt 
genom att produkten byggs med effektiv inlärning som utgångspunkt. Exempelvis bör 
begrepp som användarna känner till användas och produktens interaktion ska följa ett mönster 
som användaren förstår utan att ens tänka på det. Det är sällan som behovet av enkel inlärning 
kommer upp som krav på IT-produkter som byggs eller upphandlas. Istället finns det en 
övertro på att utbildning ska skapa en effektiv användning. Utbildning är nödvändigt för ett 
fåtal IT-produkter. Exempelvis sådana som ska stödja användarna när de löser mycket 
komplexa uppgifter och sådana sammanhang då stora ekonomiska värden står på spel eller 
människoliv, krav på service eller korrekthet. För deras del är utbildningen ett absolut krav, 
men det är också viktigt att produkten är utformad på ett sätt som hjälper användaren att lära 
vidare. Utformningen av produkten ska vara så att användaren kan tillämpa det hon/han lärt 
sig i en del av systemet i en annan del. För andra IT-produkter borde en kortare introduktion 
vara tillräcklig, dvs. de borde utformas så att de hjälper användaren att utbilda sig medan 
hon/han använder produkten. Med detta menas IT-produkter som används som ett verktyg i 
arbetet, likställt med andra arbetsverktyg. Vissa produkter används dagligen, medan andra 
används mycket sällan. Utfall av upphandling och utveckling av IT-produkter ska ske med 
fokus på inlärning och effektiv användning, för då kan tiden för utbildning minskas radikalt 
(Ottersten & Berndtsson, 2002). 


3.5.8 Verksamhetens produktivitet och kvalitet 

I många fall kan den funktionella kvalitetskomponenten vara betydelsefullare än den tekniska. 
I synnerhet gäller det om ett företag inte har några tekniska företräden jämfört med 
konkurrenterna eller om konkurrenterna omedelbart kan lansera likadana tekniska lösningar. 
Då blir det svårt att konkurrera med den tekniska kvaliteten. Konkurrensfördelar är däremot 
lättare att utveckla genom bättre funktionell kvalitet och därigenom på ett mer långsiktigt sätt 
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lyckas differentiera sig från konkurrenterna. Som en följd av tjänsternas immateriella och 
abstrakta natur är profilen hos tjänsteföretag, eller i mångfilialföretag ibland hos den enskilda 
enheten, också av betydelse för kvalitetsbilden. Kunden värderar en tjänst han överväger att 
köpa till en del efter yttre utseende och rykte. Alltså en positiv profil utgör ingen ursäkt för 
tillfälliga brister i de övriga kvalitetskomponentema, som konsumenterna då är beredda att 
acceptera. A andra sidan kan en dalig profil förstärka, kanske helt tillfälliga komplikationer, 
med den tekniska eller funktionella kvaliteten (Grönroos, 1996). 

Men vill man utveckla en ny tjänst eller ändra på existerande, bör man först slå fast vi lk en 
kvalitetsnivå man önskar uppnå och vilken profil och vilken teknikskvalitet respektive 
funktionell kvalitet man ska ställa upp som mål för utvecklingsarbetet (Ibid.). 

Grönroos (1997) menar att tjänster med hög kvalitet innebär att de anställda vet hur de skall 
göra saker och ting korrekt, meddetsamma. Om anställda inte har tillräcklig sakkunskap 
skadas kvaliteten på resultatet av tjänsteprocessen. Det innebär att kunder antagligen tvingas 
vänta längre och vara mer aktiva själva, för att uppleva en godkänd teknisk kvalitet. Kunden 
kommer att lägga märke till bristen på kunskap hos de anställda och därmed en 
sammanhörande tafatthet. Alla dessa aspekter på interaktion med företaget gör upplevelsen av 
den funktionella kvaliteten med interaktionprocessen längre. Samtidigt skadas produktiviteten 
av denna brist på kunskaper, samt behov av tillrättaläggande och upprepningar av redan 
utförda handlingar. 

Kundlojalitet är inget mål i sig, utan snarare ett steg på vägen mot bestående lönsamhet. 
Lönsamhet är heller inget slutligt mål för ett företag, utan snarare en förutsättning för 
framgång. Med andra ord är lönsamhet inte ett mål utan snarare ett medel; utan tillräcklig 
lönsamhet stannar företaget. A andra sidan är olika lönsamhetsmål kon kr eta indikationer på 
företagets konkurrenskraft och framgång (Amerup-Cooper & Edvardsson, 1998). 

En bärande tanke bakom relationsmarknadsföringen är att de kunder som företaget bygger 
upp långsiktiga relationer med skall erbjudas tjänster av hög och jämn kvalitet, vilket i sin tur 
ska leda till nöjda kunder, lojalitet och lönsamhet. Grönroos (1992) använder begreppet 
relationskostnader för att visa sambandet mellan lönsamhet och kvalitet. Resonemanget 
bygger på att en dålig kvalitet hos en tjänst skapar kostnader för både kunden och företaget. 
Relationskostnaden för kunden kan delas in i följande (Arnerup-Cooper & Edvardsson, 1998, 
s.242): 

• Direkta kostnader är sådana kostnader som kunden räknat med och som är en direkt följd 
av den lösning som erbjuds av företaget. En bankkund som förlorat sitt månatliga 
kontoutdrag och som måste ringa eller besöka banken för att få reda på saldot. 

• Indirekta kostnader uppkommer genom att kunden måste lägga tid och resurser på sådant 
som förorsakas av företagets kvalitetsbrister. I bankkundexemplet kan sådana kostnader 
uppstå om det visar sig att kontobeskedet inte stämmer och kunden måste ringa eller 
besöka banken för att rätta till saken. 

• Psykologiska kostnader är den oroskänsla som uppstår om kunden inte riktigt kan lita på att 
företaget kommer att utföra serviceleveransen på ett tillfredsställande sätt. Detta får till 
följd att bankkunden känner sig orolig över huruvida kontoutdraget kommer att stämma 
eller inte. 


25 



Informationssystem och användbarhet 


Ur företagets perspektiv uppstår också dessa tre typer av kostnader i kundrelationen (Arnerup- 

Cooperm.fi., 1998, s.243): 

• Direkta kostnader kan hänföras till att företagets system för serviceleveransen är ineffektiv 
och komplicerad. En onödig stor relationskostnad kan uppstå om bankens system vid 
utskicket av saldobeskedet är föråldrat. 

• Indirekta kostnader uppstår när bristande tjänstkvalitet leder till att man får ta hand om 
många klagomål, t.ex. då oklara eller felaktiga kontobesked måste förklaras eller rättas 
till. Personalstyrkan måste utökas eller också blir det övertidsarbete för att klara av den 
ökande arbetsbelastningen. 

• Psykologiska kostnader uppstår även för företaget genom de bekymmer och den oro som 
den dåliga kvaliteten ger upphov till. Att ta hand om klagomål är psykiskt påfrestande 
också för personalen. 

Dessa kostnader går vanligtvis inte att utläsa i företagets redovisning, varför en till synes stor 

marginal obemärkta kan ”ätas upp” av kostnader för den dåliga kvaliteten (Ibid.). 


3.6 Användbarhetsbegreppet 
3.6.1 Användarvänlighet 

En kund har beställt ett system med ett krav i kravspecifikationen som säger att systemet skall 
vara ”användarvänligt”, tänk er den situationen. Vid leverans av systemet uppstår en tvist om 
huruvida den levererade produkten är användarvänlig eller inte. I en sådan situation kommer 
oftast leverantören undan eftersom det inte är definierat vad användarvänlighet betyder 
(Gulliksen & Göransson, 2002). 

Begreppet ”användarvänlighet” har kommit att i dagligt tal vara det begrepp som används när 
man ska tala om användbara system. Användarvänlighet kan alla människor förhålla sig till, 
men när man ska kon kr etisera vad man menar blir det mycket svårare. Allwood har definierat 
begreppet som att innefatta aspektema (Gulliksen & Göransson 2002, s.57): 

o 

• Åtkomlighet 

• Förenligt med och stöd för människans mentala funktionssätt 

• Individualisering 

• Hjälpresurser 

Att definiera begrepp är bra men ofta bidrar inte denna typ av definitioner direkt till processen 
att utveckla bättre system för användarna. Detta beror på att det inte finns en enighet bakom 
begreppen eller att beställningen inte har en konkret definition. Men man kan ifrågasätta om 
huruvida datorsystemen ska vara ”vänliga” mot oss (Ibid.). 


3.6.2 Användbarhet är viktigt 

Användbarhet är en kvalitetsegenskap hos interaktiva produkter. En produkt har en hög 
användbarhet om den uppfyller beställarens och målgruppernas syften. Användbarheten hos 
en produkt visar sig i samspelet mellan produkten och dess användare över en tidsperiod - 
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kort sagt: i användning, men för att skapa en användbar produkt behöver man utforma 
produkten med hänsyn till (Ottersten & Berndtsson, 2002, s. 14): 

1. Det mänskliga systemet - egenskaper som bärs av individerna som använder produkten. 
Det finns: 

• Generella egenskaper hos målgrupperna - gemensamma mönster för hur vi människor 
ser, uppfattar och minns information. 

• Specifika egenskaper hos målgrupperna (Exempelvis kunskaper, värderingar, attityder 
och förväntningar liksom eventuella funktionsnedsättningar) som man måste ta hänsyn 
till i produktions utformning. 

2. Det sammanhang där produkten ska användas. Produkten måste anpassas till det 
sammanhang, som produkten skall användas i (Ottersten & Berndtsson, 2002, s. 14-15): 

• Det fysiska sammanhanget, exempelvis dålig belysning och störande ljud. 

• Det psykiska sammanhanget, exempelvis stress. 

• Det sociala sammanhanget, exempelvis relationer och social ställning. 

• Det organisatoriska sammanhanget, exempelvis huvudkontoret, ordermottagning. 

3. Den nytta som produkten förväntas ge. En interaktiv produkt förväntas ge någon effekt, 
bidra med någon nytta (Ottersten & Berndtsson, 2002, s. 15): 

• För den som tillhandahåller produkten, exempelvis samhällsnytta, verksamhetsnytta 
eller ekonomisk vinst. 

• För den som använder produkten, exempelvis förenkling, effektivisering eller nöje. 

Användbarhetsbegreppet har historiskt utvecklats från att enbart fokusera på det mänskliga 
systemet och se produkten i dess användning och sammanhang. De flesta modeller och 
metoder såväl användbarhets- utvecklings- och projektstymingsmodeller behandlar likväl 
kopplingen mellan den förväntade nyttan och produktens utformning ytligt, eller inte alls. 
Detta är en allvarlig brist. En produkt som inte uppfyller den förväntade nyttan kan inte anses 
var en produkt med hög användbarhet även om produkten är väl anpassad till sammanhanget 
och det mänskliga systemet. Ottersten & Berndtsson (2002) betonar behovet av att utgå från 
den förväntade nyttan för att säkerställa en produkts användbarhet (Ibid.). 

Användbarhet är ingen objektiv observerbar inneboende produktegenskap så som en färg eller 
funktion, utan användbarhet är en egenskaps om uppstår när produkten används. Quality-in- 
use eller användning skvalitet (försvenskat) där användningen av produkten kommer i fokus i 
stället för på produkten i sig själv, vilket förtydligar att användbarhet är en kvalitetsdimension 
och produktens användbarhet är beroende av det sammanhang det används i. Ottersten & 
Berndtsson (2002) anser även att produkten ska uppfylla beställarens syften för att anses som 
användbar. En stor del av litteraturen inom området och ISO-definitionen förutsätter att 
beställaren har definierat produktens syfte innan något utvecklingsarbete påbörjats. Men även 
om det finns en idé om produktens syfte, så är den ofta så vagt formulerad att den inte kan 
styra vad som skall göras i projektet (Ibid.). 
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Beställarens syften kan variera mycket beroende på verksamhetens mål. Som exempel på 
syften kan nämnas (Ottersten & Berndtsson, 2002, s.17): 

• ”Sälja mer” via en e-handelsplats. 

• ”Ge bättre service” till de boende i kommunen. 

• ”Öka kunskapen om ...”. 

• ”Effektivisera orderanläggningen” 

• ”Öka vi-känslan” genom koncerngemensamt intranät. 

• ”Vinna marknadsandelar” genom att ha en produkt med de nyaste och fräckaste 
funktionerna. 

Men ofta finns det ingen tydlig beskrivning av den förväntade nyttan. När syftet med en 
produkt är oklart blir det också väldigt svårt att utforma produkten på ett bra sätt. Beställaren 
har många gånger krav lösningar som ej är direkt användningsrelaterade. Exempel på detta 
var krav på att produktens livslängd, underhållsvänlighet, anpassningsbarhet etc. Dessa krav 
påverkas ofta indirekt på lösningens användbarhet. Användarnas syften med att använda 
produkten varierar ofta kraftigt mellan olika grupper. Därför finns det skäl att indela dem i 
s.k. målgrupper och genom att göra en målgrupps analys kan man utröna deras nödvändiga 
behov (Ibid.). 

Något som är viktigt att tänka på är att nyttan med en och samma produkt kan skilja mellan 
olika målgrupper och användningssituationerna kan vara olika. En design som är bra för en 
målgrupp kan vara dåligt för en annan målgrupp eller i ett annat sammanhang (Ibid.). 



Figur 4, ”Konstnärspensel... jag skulle ju måla huset ???” (Ottersten & Balic, 2004) 

Figur 11, ovan visar att konstnärspensel, som verkligen är effektiv när man målar tavlor, är 
helt oduglig när man ska måla huset. Tyvärr finns det många liknande exempel på interaktiva 
produkter som är dåligt anpassade till olika målgrupper och användningssituationer. 
Användningskvalitet beskriver hur väl en produkt fungerar i användningssituationen. Ett 
annat viktigt begrepp är användningsgrad , som beskriver i vilken omfattning en produkt 
faktiskt används av de målgrupper som har definierats som framtida användare. Begreppet 
användningsgrad innefattas vanligtvis ej i begreppet användbarhet. Att bygga användbara 
produkter leder inte alltid till en hög användningsgrad, eftersom användningsgraden också är 
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beroende av användarnas kunskaper, förståelse och motivation att använda produkten. 
Användningsgraden kan alltså höjas med utbildning och marknadsföring. En bibehållen hög 
användningsgrad förutsätter dock oftast att produkten har hög användbarhet (Ibid.). 

Oavsett hur beställaren formulerar sitt syfte på majoriteten av de interaktiva produkterna så är 
det summan av flera användares bruk av produkten som skapar nyttan för beställaren (Ibid.). 


3.6.3 Användbarhet enligt ISO 9241-11(1998) 

Användbarhet är centralt i den användarcentrerade systemutvecklingsprocessen och för att 
uppnå detta måste man definiera och förstå vad man menar med begreppet. Den 
internationella standard ISO 9241 ” Software ergonomics for office work with visual display 
terminals (VDTs)”, del 11 ”Guidance on usability” definierar användbarhet som (Gulliksen & 
Göransson 2002, s.62): 

Den utsträckning till vilken en specificerad användare kan använda en produkt för att 
uppnå specifika mål, med ändamålsenlighet, effektivitet och tillfredställelse, i ett givet 
sammanhang. 

Vidare definieras ändamålsenlighet som: 

noggrannhet och fullständighet med vilken användarna kan uppnår givna mål 
Effektivitet definieras som: 

resursåtgång i förhållanden till den noggrannhet och fullständighet med vi lk en 
användarna uppnår givna mål 

Och tillfredställelse definieras som: 

frånvaro av obehag samt positiva attityder vid användningen av en produkt. 

Slutligen definieras användningssammanhanget som: 

användare, uppgifter, utrustning (maskinvara, programvara och annan material) samt 
fysisk och social omgivningen i viken produkten används. 

Denna definition av användbarhet har funnits användbar eftersom den är kon kr et och ger en 
möjlighet att diskutera användbarhet med gemensam förståelse för begreppet. Dessutom 
påtalar definitionen att användbarhet är en mätbar storhet. Användbarhet kan säga att för en 
specificerad användare som utför en specifik uppgift i ett specifikt sammanhang är produkten 
X mer användbar än om produkten Y, eller att produkten Z har blivit 50 % mer användbar 
genom utvecklingsprojektet. IS O-definitionen inbegriper fler av de väsentliga aspekter som är 
viktiga för användarna än vad som avses när man diskuterar användbarhet. Det viktiga är att 
inse att användbarhet inte är en storhet utan relativa begrepp. Användbarhet diskuteras ofta av 
folk i vaga termer som ”användarvänligt'’ eller ”lättanvänd”, eller som något bara innefattar 
gränssnittet eller det interaktiva systemets grafik. Men detta är bara en del av användbarheten. 
Synsättet implicerar också att det finns ett underliggande förhållningssätt, en process. 
Användbara system kan bara utvecklas genom att lära sig mer om användarna, deras mål, 
uppgifter och användningssammanhang (Ibid.). 

Begreppet användbart används ibland för att beskriva systemets förmåga att kunna användas 
med ”lätthet”. Detta överensstämmer med den definition av användbarhet som en aspekt av 
mjukvaras kvalitet. Till exempel ISO 9126 (Information technology - Software product 
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evolution - Quality characteristics and guidelines for their use) som handlar om 
mjukvarukvalitet, definierar termen användbarhet som: 

” A set of attributes of Software which bear on the effort needed for use and on the 

individual assessment of such use by a stated or implied set of users” (ISO 9126-1, 
1991) 

Men, de attribut som krävs i en produkt för att den skall vara användbar beror på användarens, 
uppgiftens och användningssammanhangets natur. En produkt har ingen inneboende 
användbarhet utan bara en kapacitet att kunna användas av specificerade användare som utför 
specifika uppgifter i ett specifikt sammanhang. Användbarhet kan inte säkerställas genom att 
man studerar en produkt frikopplad från ett sammanhang. En penna får exempel fixeras. 
Användbarheten kan inte utryckas enligt 9126, däremot skulle man kunna mäta hur hållbar 
den är genom att ta den till Statens Provningsanstalt. Men, skall användbarhet bedömas enligt 
9126, så tillstöter de faktorer som beskrivs i ISO 9241, del 11 (Ibid.). 

Att välja ISO:s definition av användbarhet ger ett mycket vidare grepp om användbarhet än 
tidigare definitioner. I takt med de ökande problemen med IT-stöd i arbetslivet känns det 
värdefullt att ha en definition som försöker ta ett helhetsgrepp om problematiken. Dessutom, 
det faktum att det är en internationell standard gör det mycket enklare att oomtvistat införa ett 
sådant begrepp i en organisation (Ibid.). 

Användbarhet enligt ISO:s definition är ett betydligt vidare begrepp än det som användbarhet 
anses vara i dagligt tal. Användbarhet innefattar hela systemet bredd ur användarens 
perspektiv från funktionalitet till upplevelser av de erotiska värdena. En av de viktiga 
utgivningarna är att även systemtes etiska värden är av betydelse för användbarheten, 
nämligen användarnas tillfredsställelse i användningen av systemet. I begreppet 
användnings sammanhang i vilka, målsättningen användaren har utan även i det sammanhang 
vilket systemet används är av betydelse för användbarheten (Ibid.). 

ISO ser på användbarheten som en mätbar storhet, dvs. man skall kunna kvantifiera i vilken 
utsträckningen något är användbart samt t.ex. kunna ange användbarheten i relation till någon 
annan produkt. I och med det kan man avgöra om en insats har en given avsedd effekt i 
termer av förhöjd användbarhet. Det finns givetvis en stor mängd metoder för att kvantifiera 
olika aspektema av användbarhet. Huvudsakligen är det effektiviteten som kan mätas i termer 
av tid för att utföra vissa arbetsuppgifter. Dessutom kan ändamålsenligheten skattas t.ex. 
genom att mäta i hur stor utsträckning man faktiskt genomför sina arbetsuppgifter, eller att 
mäta felfrekvensen och tiden att återhämta sig från fel. Enkätstudier kan också användas för 
att mäta användartillfredsställelsen (Ibid.). 

Vidare är definitionen viktig i och med att den går att kon kr etisera och omsätta i metoder och 
inte minst gör det möjligt att fokusera på användbarhet i systemutvecklingsprocessen. ISOs 
definition av användbarhetsgreppet innehåller inte bara de aspekter som traditionellt sett 
används och betraktas som mätbara, nämligen effektivitet och ändamålsenlighet. Den 
innehåller tillfredsställelse, vilket inte är lika lätta att förstå hur man skall kunna mäta 2 . 
Användbarhet tolkas ofta som av systemutvecklare som det man brukar benämnas ”icke¬ 
funktionella krav”. Men användarcentrerad systemdesign däremot, handlar det om att 


2 Gulliksen & Göransson (2002) menar att det alltid går att försöka sätta mått på kvantitativa aspekter. 
Tillfredsställelse skulle man kunna skatta. De värden som man då erhåller ger givetvis inget absolut mått men 
kan användas vid t.ex. upprepade skattningar med samma användare som utför samma arbetsuppgifter 
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specificera såväl funktionella som icke-funktionella krav med användarna i centrum. 
Konsekvensen av att se användbarhet som enbart icke-funktionella krav blir då att man ser 
användbarhetsarbete som bara handlar om yta, och då tappar man många aspekten av 
användbarheten (Ibid.). 

Användbarhetsarbete tolkas ibland som att jobba för att systemet ska erhålla 
användaracceptans. Visst är det viktigt att användaren accepterar systemet. Gulliksen & 
Göransson (2002) har sett ett otal exempel på system som haft kraftiga användbarhetsbrister 
men accepteras av användarna. Det går inte att utveckla system med syftet att höja 
användarnas acceptans utan acceptansen är snarare en följd av en mycket större process som 
inbegriper underhåll, införande och en mängd andra aspekter (Ibid.). 

Användbarheten är dock inte endimensionellt begrepp menar Nielsen (1993) utan associeras 
till följande attribut (Gulliksen & Göransson 2002, s.66): 

• Lätt att lära: Detta för att användaren snabbt ska komma igång med arbetet. 

• Effektivt att använda: Det måste vara effektivt att arbeta med när användaren lärt sig 
systemet. 

• Lätt att komma ihåg: Det måste gå att komma tillbaka till systemet efter en tids frånvaro 
och ändå kunna komma ihåg hur det fungerar. 

• Få fel: Användarna ska kunna göra så lite fel som möjligt. Om det blir fel så måste det gå 
att komma tillbaka till situationen innan felet uppstod. 

• Subjektivt tilltalande: Det skall kännas bra att använda systemet. Man skall tycka det är 
tilltalande att jobba med systemet, alltså måste man tycka om det. 

Dessa attribut kan tjäna som en inspirationskälla när man skall ange mätbara 
användbarhetsmål, likafullt utan att täcka alla aspekter av användbarhet enligt ISO. 

Nielsens och Shneidermans aspekter har man försökt att sätta i relation till ISO:s definition av 
användbarhet (se tabell 1). Dessa attribut stämmer ganska väl överens med ISO:s definitioner 
av användbarhet, dock så är kopplingen till ändamålsenlighet svag. Gulliksen & Göransson 
menar att enligt deras erfarenhet så täcker effektivitet, ändamålsenlighet och tillfredsställelse 
som begrepp de aspekter av användbarhet som man behöver kunna mäta. Men 
användbarheten bör beaktas i sin fulla bredd och därför behöver alla tre begrepp tas med i 
beräkningen (Ibid.). 


Tabell 1, Mätbara aspekter av användbarhet enligt ISO 9241-11, Shneiderman och Nielsen, (Gulliksen & 
Göransson 2002)_ 


ISO 9241-11 

Shneiderman 

Nielsen 

Effektivitet 

Tid att utföra en uppgift 

Tid att lära 

Effektivitet att använda 

Lätt att lära 

Ändamålsenlighet 

Kvarhållande i minnet 

Över tid 

Frekvens användarfel 

Lätt att komma ihåg 

Få fel 

Tillfredställelse 

Självupplevd 

Tillfredsställelse 

Subjektiv tilltalande 
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Gulliksen & Göransson visar att Dix å andra sidan definierar tre huvudsakliga grupper av 
begrepp som är på samma abstraktionsnivå (se tabell 2). 

Tabell 2, Faktorer för användbarhet så som de beskrivs av Dix enligt Gulliksen & Göransson 2002 


Lärbarhet 

Flexibilitet 

Stabilitet 

Förutsägbarhet 

Dialoginitiativ 

Observerbarhet 

Syntetiserbarhet 

Multitrådning 

Felhjälpningsförmåga 

Igenkänningsbarhet 

Uppgiftsmigrering 

Svarsförmåga 

Generaliserbarhet 

Ersättningsbarhet 

Uppgiftsöverensstämmelse 

Konsekvens 

Anpassningsbarhet 

Tillfredsställelse 


Lärbarhet: den lätthet med vilken nya användare effektivt kan integrera och uppnå maximal 

prestation av Dix enligt Gulliksen & Göransson (2002, s.68-69). 

• Förutsägbarhet - Stöd för användarna för att avgöra effekten av sina handlingar baserat 
på tidigare interaktion. 

• Syntetiserbarhet - Stöd för användaren för att avgöra i vilken mån användarens tidigare 
handlingar bidraget till systemtes nuvarande tillstånd. 

• Igenkänningsbarhet -1 vilken utsträckningen användaren kan använda sin kunskap och 
sina erfarenheter från såväl omvärlden som datormiljöer i interaktionen med det nya 
systemet. 

• Generaliserbarhet - Det stöd som användaren får för att kunna öka kunskapen om 
specifik interaktion i den aktuella och andra applikationen till andra likartade situationer. 

• Konsekvens - Likhet i inmatnings- och utmatningsbeteende i likartade situationer eller vid 
likartade uppgiftsmål. 


Flexibilitet: den mängd olika sätt som användaren och systemet kan utbyta information. 

• Dialoginitiativ - Befriar användaren från den begränsning som en tvingande 
inmatningsdialog medför. 

• Multitrådning - Systemets förmåga att stödja användaren i att genomföra mer än en 
uppgift samtidigt. 

• Uppgiftsmigrering - Möjlighet att överföra kontrollen över uppgiftens utförande mellan 
system och användare. T.ex. vid stavningskontroll behövs en rimlig uppdelning över hur 
mycket systemet skall göra och hur mycket användarna bör göra. 

• Ersättningsbarhet - Möjliggör alternativa inmatnings- och visningssätt för användaren. 
T.ex. inmatning av datum konverteras till standarformat, eller inmatning i kalkylark där en 
inmatning kan resultera i förändrade värden i andra celler. 

• Anpassningsbarhet - Användarens eller systemets möjlighet att anpassa 
anv ändargräns snittet. 

Stabilitet: Där stöd som användaren får för att avgöra hur framgångsrikt målen har uppnåtts. 
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• Obser\’erbarhet - Användarens möjlighet att avgöra systemets inre tillstånd baserat på en 
representation som kan uppfattas. 

• Felavhjälpningsförmåga - Användarens förmåga att kunna vidta korrekta åtgärder när ett 
fel har upptäckts. 

• Svarsförmåga - Hur användaren uppfattar graden av kommunikation med systemet. 

• Uppgiftsöverensstämmelse - Den grad i vilken systemtjänsterna stödjer alla de uppgifterna 
som användaren önskar utföra på det sätt som användaren uppfattar dem. 

Vid en jämförelse mellan dessa kategoriseringar och definitioner blir det tydligt att ISO - 

Standarden och Nielsen ger en tydlig inramning till begreppet användbarhet medan Gullikson 

& Göransson menar att Dix m.fl. mer fokuserar på kon kr eta delar som påverkar användbarhet 
(Ibid.). 
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4. Introduktion till problemlösningsprocessen 

Här redogör jag för den teori som ska introducera läsaren i en problemlösningsprocess och i 
princip hela kapitlet är baserat på Jayaratna (1994). Teorin ska även möta delar av ramverkets 
utvärdering av mina valda metoder. Jayaratna har åtta steg definierade i 
problemlösningsformuleringen men jag kommer endast att använda de första fyra stegen. 
Först presenteras underlagen för hur en problemlösningsprocess, diagnos och prognos bör 
följas. 

4.1 Problemsituationen 

De flesta problem ses utifrån organisationens kontext, men varför är organisationens kontext 
så viktig för metoden, när fokuserandet ändå bara är utifrån att utarbeta processer för 
informationsflödet? Men organisationen är viktig för metoden av flera orsaker. En orsak är 
om informationsprocesserna kan effektiviseras och informationen är väl genomtänkt för 
användaren i organisationen. Men är det bara få av organisationens användare som stöds av 
informationen. Eller om det saknas kunskap om vad användarna producerar och gör med 
informationen. Då kommer ingen effekt att skapas, vilket innebär att effektiviserandet 
kommer att misslyckas. Därför bör informationssystemsspecialist om arbeta nära användarna, 
för att följa arbetet på nära håll och få förståelse för vad som görs och vilka funktioner som 
finns och bör finnas. Detta skapar en förståelse för organisationens aktiviteter, menar 
Jayaratna (1994). 

För att kunna utveckla effektiva informationssystem bör arbetet ske i nära samband med 
organisationen och deras användare. Det är viktigt att förstå vilken information de använder 
och varför. Vilka problem försöker de lösa i organisationen och vilka behov ska 
tillfredsställas? 

Det är viktigt att problemlösaren, oavsett om denne kommer inifrån organisationen, eller 
utifrån verkligen får en ordentlig överblick över hela organisationen inte bara över 
problemområdet. Problemlösaren som kommer inifrån och som redan har kunskap om 
organisationen kan behöva göra en mer rigorös och kritisk granskning. Detta för att få ett 
mera insiktsfullt perspektiv på situationen. 
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Figur 5, Organisationens dimensionsmodell fritt tolkat efter Jayaratna (1994) 

En svaghet som det flesta system utvecklingsmetoder har är att de inte bryr sig om vad som 
verkligen händer i organisationen. De begränsar sig till att hitta information till användarens 
krav och utvecklar sedan processer som ska stödja dessa. När sedan dessa är tillgodosedda, så 
är uppgiften avslutad. Detta beror till stor del på att metoderna inte erbjuder någon hjälp att 
förstå och omvandla resultat som påträffas vid olika perspektiv och situationer. En stor vikt 
bör läggas på att förstå organisationen och dess syfte, för att kunna designa ett bra system. 
Systemet designas sedan efter dessa aktiviteter och syften. Genom den enkla modellen som 
illustreras i figur 4 visas samspelet mellan de fyra dimensionerna. Det är viktigt att notera att 
en modell inte kan påvisa den komplexitet eller dynamik som råder i en organisation. Vissa av 
aspekterna är oerhört svåra att fånga och beskriva i diagram eller i andra former. Exempelvis 
kan det vara svårt att beskriva de emotionella känslorna som finns mellan individer i en 
modell som nedan. Men trots det kan en grafisk figur på ett effektivt sätt illustrera idéer, 
fakta, åsikter, begrepps, etc. 

För att ”problemlösaren” ska bli en effektiv problemlösare måste en djupare förståelse för 
organisationen först inhämtas. NIMS AD använder en generell modell över de nödvändigaste 
elementen över problemsituationer och deras formella och informella sammanbindningar och 
relationer. Det är viktigt att notera att dessa sammanbindningar är dynamiska inte bara i tid 
och plats, utan också beror av ens egen uppfattning, vilket innebär att olika människor 
uppfattar/noterar olika saker beroende på vilket perspektiv de har, t.ex. mänskliga relationer, 
arbetsprocesser eller tekniska lösningar. Till hjälp att fokusera på rätt information för 
systemets kontext, visas en del signifikanta aspekter för organisation, som illustreras i figur 4. 
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Figur 6, "Problemsituation" (action world) fritt tolkat efter Jayaratna (1994) 

4.2 Tänkt problemlösning 

En bra och kraftfull metod kan vara de verktyg som skapar en grund för att designa ett 
framgångsrikt informationssystem. Det finns ett antal praktikfall identifierade från industrin 
som kan vara till stöd att utforma denna process. Dessa kan utgöra problemlösarens mentala 
struktur. 

En tänkt problemlösningsmodell som avsiktligt väljs för att vara human har en benägenhet att 
välja element ur situationen som är relevanta och användbara att studera och transformera. 
Vissa av dessa urval görs underförstått och omedvetet, medan man andra gånger väljer en mer 
tydlig konceptmodell och metod. Vad är det som avgör vilka element en problemlösning 
väljer ur den” aktiva världen” som relevant, signifikant eller oduglig? Hur de väljer eller gör 
sammandrag ur den ” aktiva världen” eller vilka hänsynstagande gör de? Vad är innebörden 
av detta urval? Det är frågor som bör besvaras och speciellt viktigt för den tänkte 
problemlösaren. 

Utifrån industriarbete och konsultuppdrag har Jayaratna identifierat ett flertal kännetecknen 
för att upprätta den tänkta problemlösarens ”mentala tankeskapelse”. Detta illustreras i figur 
5. 
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1. Perceptual process 
3. Values/ethics 
5 .Motives and prejudices 
7. Reasoning ability 
9. Experiences 


2. Skills and knowledge sets 
4. Structuring process 
6. Roles 

8. Models and framework 
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Tänkt problemlösning 
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Figur 7, Den mentala tankeskapelsen, fritt tolkat efter Jayaratna (1994) 

Den Perceptuella processen är den mest påverkande och utmärkande för problemlös arens 
mentala struktur. Den agerar som ett filter mot den aktiva världen och bestämmer om den ska 
vara betydande. Varje person uppfattar ”verkligheten” på olika sätt. Ibland räcker det inte att 
identifiera och lösa problem i den verkliga världen. Hänsyn måste också tas utifrån andra 
intressegrupper, som inte definierar problemet på samma sätt. Har vi inte samma förståelse 
inför problemet så kommer det att innebära att vi inte löser problemet, eftersom vi har olika 
syn på problemet menar Jayaratna (1994). 

Vi utgår från att våra värderingar ska vara goda. Vår värdegrund har influerats av föräldrar 
och tidigare arbetslivserfarenheter etc. Dessa värden ligger sedan till grund för bedömningar 
av situationer och beteenden vi iakttar. Exempelvis om ett problem är av en ekonomisk natur 
och berör ett stort antal anställda och deras arbetsinsats. För att belysa detta fall, kan det 
behövas goda sociala värderingar för att utreda problemet effektivt, och då inte bara utifrån de 
ekonomiska värderingarna. Värderingar styr vår personlighet och finns värderingar som är 
mer dominanta än andra. 

Etik är något vi förväntar oss att andra personer ska handla efter. De flesta problemlösare vet 
att det är oetiskt att avslöja källan till informationen. Professionella institutioner, 
intressegrupper och organisationskulturer och ens egna värderingar är dikterade ur etiska 
normer och värderingar och måste följas i en given situation. 

Motiv är valda behov som vi försöker tillfredsställa i en given situation men behåller det för 
oss själva. Men många kan välja en problemsituation att lösa efter personliga motiv, medvetet 
eller omedvetet för att tillfredsställa sig själv. Behov eller inte, Maslow’s (1943) och 
Hertzbergs (1959) gamla teorier ger en verklig förståelse för det personliga behovet. 

Industrins aktiviteter visar att dessa behov påverkar designlösningama och hur metods 
används i praktiken. 


37 



Introduktion till problemlösningsprocessen 


Våra förutfattade meningar begränsar oss, de formas av värderingar och erfarenheter utifrån 
osäkerhet och ovisshet som vi upplever. Det kan göra att vi inte ser nya möjligheter utan 
begränsar oss i vårt tänkande. Därför måste vi öppna upp och ta oss förbi detta mentala 
hinder. T.ex. har vi dålig erfarenhet från en viss teknologi, så frodas vår fördom från just detta 
misslyckande, vilket innebär att vi inte tänker i nya bannor. Därför är det viktigt att vi 
verkligen ifrågasätter våra fördomar genom feedback från andra runtomkring, annars kommer 
vi att fortsätta leva i våra fördomar och kommer inte vidare. 

Erfarenheter är en värdefull källa för kunskap och skicklighet, vilket underförstått hjälper oss 
att nyansera och strukturera vår förståelse för en given situation. Modellen föreskriver 
återigen vilken information som söks och ges i en given situation. Ju mer erfarenhet vi har av 
ett bestämt arbetsområde, desto lättare att fastställa liknande situationer. Erfarenhet gör oss 
trygga och kan ge oss en expertstatus. Erfarenhet kan även bidra till att minska tidsåtgången 
och tillhandahålla en rad av enkla lösningar och utveckla vårt förtroende. Men samma modell 
kan även hindra oss att se nya idéer, vilket medför att dessa nya idéer inte kommer fram och 
kan diskuteras. 

Vårt resonemangs förmåga är den skicklighet vi har att se de grundläggande aspektema för en 
situation och genom att förstå de underlydande koncept som gäller i processen. För vissa 
kommer det naturligt med om andra måste träna upp förmågan genom utbildning, träning och 
egna reflektioner. Den förmågan hittas inte genom att personen testas i ett logisk IQ - test. 
Personen kan misslyckas med IQ testet men ändå inneha förmågan att tänka i olika banor. Det 
är just förmågan att i en problemlösningsprocess fokusera och förklara varje tankeval genom 
processen. 

Det är nödvändigt med utbildning och erfarenhet för att förstå resultatet av en situation. 
Exempelvis som informations specialist måste man förstå den information som flödar mellan 
organisationsmedlemmar. Men även den relation som råder mellan informationsanvändare. 
Som problemlösare måste man vara medveten om den kunskap och skicklighet som begärs 
för att använda metod, men även metodutvecklaren bör uppge vilken kunskap som krävs för 
att behärska metoden. Det skulle ses som ett hälsotecken för varje metod. 

Att strukturera processer är unikt för varje individ. Metoder kan på olika sätt hjälpa oss 
strukturera vårt tänkande och handlande i olika diagram. Det ska även hjälpa oss att se 
situationer på olika sätt. 

En Roll kan tydligt definieras utifrån en karaktärs beteende, som sedan appliceras på den som 
ansvarar och utföra en arbetsuppgift. Den förmågan vi har att utifrån rad olika karaktärer 
framställa en roll utifrån en position med ansvar och auktoritet. Exempelvis så förutsätter vi 
utan att tänka, att mätning av prestation är en attributet för manager, revisor, eller redovisare. 
Den roll vi intar kan också skapa höga förväntningar utifrån andra som har haft vår uppgift. 
Olikheter kan leda till konflikter, hur rollen och uppgiften ska utföras. Med vårt eget 
handlingssätt och personlighet, för att bekräfta andras förväntan på oss, kan uppgiften leda till 
personlig stress. Noteras bör att när vi är engagerad en ”organisations politik” berörs vi inte 
av denna påverkan, eftersom vi ser organisationen som ett spelbord eller stridsfält, där 
kampvilja demonstrera, av oss. Man kan bli väldigt glad att få anta en rolls beteende och 
värderingar så länge det hjälper oss att maximera våra personliga behov och motiv. Men om 
vi då innehar eller läggar oss till med egna specifika värderingar av etiska och moraliska 
värden. Och roll karaktären förväntas vara baserad utifrån andra förväntningar, kommer detta 
att skapa betydande påfrestningar. Skälet till att detta förbises är att den tänka problemlösaren 
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inte undersöker omständigheterna tillräckligt noggrant, utan väljer istället andras roll som kan 
vara offer eller förmånstagare av deras handlingar. Den tänkta problemlösaren måste 
undersöka vilken typ av roll som förväntas av dem i en given situation eller anta en attityd 
och hålla den i en given situation, och ta fullt ansvar för rollen dess handlingar. Det är metod 
skapare som måste förklara den förväntan som ställs och vad det innebära för metoden hävdar 
Jayaratna (1994). 


4.3 Den mentala tankeskapelsen 

Som problemlösare måste den egna tankeskapelsen ifrågasättas menar Jayaratna (1994). För 
genom att ifrågasätta sina egna tankebanor och förförståelse kan nya tankebanor öppna för 
nya företeelser och perspektiv, vilket skapar en förståelse för vad som karakteriserar våra 
känslor och beslutstagande. 


4.4 Problemlösningsprocessen 

Jayaratna (1994) påpekar att, för att en metod ska vara till stöd vid en problemlösning, måste 
den visa att den kan stödja och förbereda för de tre mest grundläggande faserna. Dessa tre 
faser kan utvecklas i form av åtta detaljerade steg, vilka sedan kan appliceras på vilken 
problemlösningsprocess som helst. 

Faser i problemformuleringen: 

Steg 1: Förstå ”situation av intresse” 

Steg 2: Förbereda en diagnos 
Steg 3: Definiera en prognos 
Steg 4: Definiera problem 


4.4.1 Steg 1 Förstå situation av intresse 

Problemlösning i en organisation är en komplex aktivitet. Innan någon problemlösning ens 
kan göras måste en fördjupad förståelse ha skapats över den situation som råder mellan olika 
personers perspektiv av problemet. Utan den insikten går det inte att formulera eller föreslå en 
lösning. Att se problemet från olika nivåer hindrar inte problemlösaren att komma med en 
lösning. Den förnuftiga problemlösaren vill ha en ”god” förståelse för situationen. Detta 
åstadkoms genom att den interna och externa problemlösaren noggrant har genomlyst 
problemet, men även själv har bearbetat de mentala tankemönstren. Detta skapar tillsammans 
en unik förutsättning problemsituationen. 

För det första hjälper det till att dra en gränslinje för situationen och därefter identifiera 
möjligheter ” för intressanta områden” se figur 6. 


39 



Introduktion till problemlösningsprocessen 



Figur 8, Gränslinje av intresse, fritt tolkat efter Jayaratna (1994) 

Detta är även ett bra sätt att förstå organisationens beteende menar Jayaratna, och detta kan 
vara avgörande för en problemlösare. Om problemlösaren inte ifrågasätter sin egen ”mental 
tankeskapelsen” så kan en gränslinje dras utifrån andras mentala konstruktioner. Det kan då 
medföra att en underförstådd gränslinje dras, som vi inte medvetet har konstruerats. Eftersom 
gränslinjen ska avgöra och bestämma fokus för undersökningen och ”situationen av intresse”. 
Därför behöver problemlösaren utvärdera att de relevanta elementen är identifierade, som 
personer, material, aktiviteter och flöden. Det är något som den valda metoden ska stödja. 
Problemlösaren måste sedan vara förberedd att arbeta på denna nivå. För om inte den 
förmågan uppnåtts, att se de relevanta elementen, kommer inte heller någon effekt att fås av 
den valda metoden. Det kan vara så att problemlösaren inte känner igen effekten av den valda 
metoden på den konstruerade och dragna gränslinjen. Figur 7 visar den ”mentala 
tankeskapelsen” på en planerad problemlösning med en dragen gränslinje, och element för 
undersökningen och påföljande design. 

Den ”mentala tankeskapelsen” hjälper problemlösaren att avgöra vilken information som ska 
samlas in. Förutsatt att ramverkets modell avgör vilken information som bör insamlas. Desto 
rikare ett ramverk är av den ”mentala tankeskapelsen” desto mer rigorösare examineringar av 
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situationer och ju mer öppen blir problemlösaren till den konstgjorda miljön runt gränslinje av 
”situation av intresse”. 

Generellt finns det många tekniker publicerade och vida diskuterade inom ämnet 
informationssystem. Många diskussioner handlar om valet av undersökningsmetoder som 
uteslutande handlar om ett praktiskt perspektiv s.k. frågemetoder. Där information insamlas 
genom att fråga de anställda eller annan större grupp människor spritt geografiskt i en 
population. Som tillägg till dessa metoder finns checklistor och hur man förbereder dessa 
undersökningsaktiviteter. 

Därför bör varje steg av en metod utvärderas, men även den egna ”mentala tankeskapelsen” 
och det dynamiska samspel som råder med klienterna i den rådande situationen. Alla dessa 
faktorer kan kollektivt påverka vår konstruerande gränslinje. Men varför behöver den 
konstruerade gränslinjen begrundas i en problemlösning? Jo, för att det inkluderar så många 
olika element från början, därför bör problemlösaren följa stegen i problemlösnings - 
processen. Uppmärksamheten är riktad framåt och fokuserar på elementen i 
”gränslinjekonstruktionen” - se figur 7. Om orsaken till identifierade problem skulle ligga 
utanför gränslinjen, spelar det ingen roll hur väl substansen i gränslinjen är designad eller 
transformerad, problemet kommer inte att bli löst. Därför kallas denna selektion för ”situation 
av intresse” och Jayaratna rekommenderar att problemlösaren ska utvärdera och examinera 
sin egen ”mentala tankeskapelsen” kontinuerligt. 


4.4.2 Steg 2 Förbereda en diagnos 

Vad gör vi nu, med den insamlade informationen från situationen? I de flest fall av 
problemlösningar har problemlösaren lagrat allt i sitt huvud, baserat på den ”mentala 
tankeskapelsen” för ”problemsituationen”. Men har problemlösaren många element och 
dynamiska interaktioner eller komplexa relationer, behöver problemlösaren något ytterligare 
sätt att uttrycka sin förståelse med. Diagnosen är explicit projektering eller uttryck av 
förståelse för problemlös arens undersökning. Vanligtvis är det uttryck i statisk, i form av 
frusna bilder eller fotografier av ”situation av intresse”. Denna form av uttryck beror mycket 
på den teknik och verktyg som finns till förfogande, vilket problemlösaren är mest förtrolig 
med för ”situation av intresse”, och den förmåga problemlösaren har att sammandra 
nödvändigt element ifrån. Men problemlösaren bör veta att detta uttryck är mycket av en 
funktion av ömsesidighet eller samspel mellan två dynamiska förlopp (”situation av intresse” 
och vår ”mentala tankeskapelsen”) med respekt för ett särskilt belägg av tid. Figur 7 visar 
resultaten av förståelse uttryckt i diagnos, men det kan inte förväntas att problemlösaren ska 
uttrycka det lika representativt och uppenbart, som den komplexa miljön av beteenden för 
element i ”situation av intresse” I detta skede är beskrivning viktigare och det är mer relevant 
att problemlösaren är införstådda med den planerade problemlösningen och förstår varför 
detta tillstånd råder på ”situation av intresse”. 
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Figur 9, Diagnos, fritt tolkat efter Jayaratna (1994) 


Diagnosen ska forma basen för steg 1 i påföljande problemlösning. Förståelse för att ju mer 
dynamisk miljö för situationen desto längre bort från relevant data för diagnosen, som inte är 
representativ för ”situation av intresse”. Problemlös aren ska även examinera den relevans av 
teknik och verktyg för miljön, förutsatt att metoden uttryckt en förståelse för exempelvis 
dataflödesdiagram rika bilder etc. Det finns igenom modell eller teknik som är kapabel att 
fånga in den komplexiteten av den givna situationen. Men det kan hjälpa problemlösaren i 
den omfattning att den uppmärksammar problemlösarens ”mentala tankeskapelsen” för de 
kännetecken som finns för elementen i situationen. Det hindrar problemlösaren i en viss 
utsträckning att stänga av sinnen som inte kännetecknar uttryck, och som inte är adresserade 
av modellen. Exempelvis användandet av dataflödesdiagram kan hjälpa till att fokusera på 
formell data, men det kan också stänga problemlösarens sinnen för informell och 
oregelbunden kommunikation av situationen. 

Diagnosen stödjer ytterligare tre behov. 

1. En tydlig formulering av problemlösarens förståelse för situationen hjälper till att 

identifiera kunskapsluckor och missförstånd. Härefter kommer själva processen att träna 
och lära om situationen, därigenom förbättrar problemlösaren sin förmåga att återge en 
modell av situationen mer effektivt. 
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2. Formuleringen hjälper problemlösaren att kommunicera särskilt med klienter och 
problemägare för att inhämta samtycke, förståelse och klargöra olikheter i iakttagelser. 
Men även förtydliga de olika syner som finns om systemutvecklingsmetodema. 

3. Formuleringen tjänar som basis för åtagande i framtida aktiviteter för problemlösningen, 
och kan vara i olika former. Men det är självklart, hur väl och rika formuleringar det kan 
görs så beror det ändå på vilken teknik modellen använder för att utrycka formuleringarna. 

Det två huvudsakliga nivåerna har identifierats syfte och problemlösning. Den första innebär 
att problemlösaren har identifierat den konceptuella/logiska utformningen. Den andra nivån 
illustreras i figur 8, där uttrycks den fysiska karaktären av ”situation av intresse”. Den kan 
täcka de aktuella produkterna, specifika individer, dokument, datorer etc. I detta fall och 
eventuellt senare kan det inkludera tempo, kapacitet, prestanda, volym, statistik och kostnader 
etc. 


4.4.3 Steg 3 Definiera en prognos 

Vad vill vi vara och varför? Det två föregående stegen var koncentrerade runt rollen som 
blivande problemlösare, vi lk et skapa en djupare förståelse för ”situation av intresse”. 
Grundläggande fokus för en diagnos är till för att hjälpa problemlösaren att klargöra sin 
förståelse, men även för att klargöra hur organisationens medlemmar kommunicerar med 
varandra. När denna förståelse har klarlagts och en förståelse för hur det hela hänger samman 
är tydligt för problemlösaren, då ska problemlösaren ställa sig frågan; Varför då? 


Problemformulerandefasen 



Prognos 



Diagnos modell 1 


Figur 10, Prognosskissen, fritt tolkat efter Jayaratna (1994) 

Svaret på den frågan är att klienten eller problemägama gillar detta tillstånd. Detta leder till 
definitionen av ”prognos”. ”Prognosen” är uttryckt önskad situation. Detta steg avser att 
definiera önskat tillstånd för den aktuella ”situation av intresse”. Det önskade tillståndet är 
illustrerat i figur 8 med dragen gränslinjen. Det har medvetet dragits för att vissa att det skiljer 
mellan ”prognos” och diagnos”. Prognosens utkast visar ”önskat tillstånd” medan diagnosens 
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utkast visar ”aktuellt tillstånd”. Det är viktigt för kommande diskussion att ha en förståelse för 
innebörden av de olika lägenas tillstånd, på en konceptuell nivå som låter oss definiera vilka 
problem som helst: 

Skillnaden mellan begreppet ”verkliga” och begreppet ”förväntningen” 
på den ”verkliga”, kan tillsammans göra att begreppet ”förväntningen” 
blir ”verkligt” (Jayaratna, 1994, s.104). 

Genom att använda definitionen, kan en förståelse för vilka problem som helst av mänskliga 
aktiviteter skapas. 

En av de allvarligaste svagheter som många metoder har, är att de tvingar användarna att 
acceptera ett särskilt mentalt tillstånd, prognosplanen (önskat tillstånd), utan att kritiskt 
utvärderat eller examinerat frågorna. De flesta metoder kan inte ens uppmärksamma 
användarna på det ”önskade tillståndet”; vilket förblir enskilt för klinterna och 
problemägarna. Dessutom behöver problemlösaren inneha stark motivation och ifrågasättande 
om dessa frågor som ställs om det ”önskade tillståndet” för klinterna ska accepteras eller inte. 

Låt oss anta att klinterna och problemägama har en mer ingående kunskap om den ”verkliga 
världen” och har goda skäl för deras förväntan. Inte ens då, om de är utrustade med en 
relevant modell och är väldigt skickliga, kan problemlösaren inte strunta i att examinera och 
validera deras förväntan rigoröst. I många av dessa resonemang har klinter ändrat sina krav 
under systemutvecklingens gång. 

Frågor kring förväntningarna är sällsynta inom många områden av problemlösningar. Detta 
misslyckande, att validera frågorna om det ”önskade tillståndet” leder till att irrelevanta och 
dyra lösningar implementeras, med signifikant underhåll. När ett ”önskat tillstånd” är 
accepterat utan frågor, antigen för politisk oro eller andra pragmatiska skäl, finns det väldigt 
liten möjlighet att diskutera de ”verkliga” problemen”. I vissa industriprojekt har Jayaratna 
hjälpt klinter att omvärdera deras ”önskade tillstånd” genom att diskutera och belysa 
tillståndet. 

Efter detta steg kan vi definiera konturen och utformningen av den logiska grunden (utan 
innehåll). När konturerna är definierade och etablerade kan hänsyn tas till, vilket innehåll som 
ska stödja en formell miljö. Problemlösaren får hoppas att det finns tillräckligt med kunskap 
för att tillfredställa och stödja utformningen av konturen av diagnosen. 

Låt oss anta att utkastet och strukturen är en diagnos för organisationens ”aktuella 
tillståndsnivå” av lönsamhet eller markands andelar, politisk status eller kultur. Prognosen 
skulle då formas som ”önskat tillstånd” för att klienternas önskemål är att se en ökad 
lönsamhet, ökade marknadsandelar, en annan politisk status eller samarbete, etc. Diagnosen 
inkluderar tillfredsställelse och ger oss råd och förståelse för vilka funktioner, roller, 
produkttyper, markands andelar, etc. Modellen, diagnos modell 2 kan specificera hur 
produkter, service, personer, etc. ska utformas för dessa funktioner. Men problemlösaren vet 
inte hur i detta steg. Vilka aktiviteter, aktioner, funktioner, roller, etc. som är nödvändiga för 
att framkalla de ”önskade tillståndet”. Därför kan prognosmodellen i detta steg endast visa ett 
utkast. Fokus är inte att skapa gillande för prognosmodellen, utan att förstå varför den måste 
gestaltas så för att t.ex., öka markands andelarna. Det är väldigt berättigande frågor att ställa, 
vilket mycket väl kan leda till att projektet upphör eller ge upphov till konflikt med klienten. 
Inte någon av klinterna vill svara på den frågan, då det är för logiskt för hans/hennes 
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förväntan. Men det är den typ av frågor som hjälper problemlösaren att säkra relevansen av att 
design bemöter det ” önskade tillståndet”. Det skapar en förståelse den blivande 
problemlösaren överger sitt intellektuella resonemang och antar politiska resonemang när de 
står inför dessa typer av situationer (Jayaratna, 1994). 


4.4.4 Steg 4 Definiera problem 

Nu när problemlösaren förhoppningsvis vet anledningen till det ”önskade tillståndet”, undrar 
man vad som förhindrar detta tillstånd. Med andra ord, vad är nästa steg i 
problemlösningsprocessen för att finna det ”önskade tillståndet”. 



Prognos 


Diagnos modell 1 



Diagnos 


= Problemområde 


Figur 11, Problemdefinition, fritt tolkat efter Jayaratna (1994) 

Nu när problemlösaren förhoppningsvis har kommit fram till ”aktuellt tillstånd”, vad är det då 
som eventuellt kan förhindra att förändringen? Med andra ord så ska problemlösaren förstå 
vad som kan stå i vägen för det ”önskade tillstånd ” alltså prognosens utkast. Denna process 
kan beskrivas som den konceptuella kartläggningen av två olika tillstånd (notera, detta är 
uppfattade tillstånd). Ursprungligen är skedet till att fylla en lucka i analysen, där uppgiften i 
detta steg är att identifiera och kritiskt examinera: 

• frånvaro av element 

• organisation (aktuellt arrangemang) av elementen 

I diagnosmodellen förhindrar den det ”aktuella tillståndet” från att förändras till det ”önskade 
tillståndet”. 
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Figur 9, visar resultatet av en kartläggning och denna process leder till att identifiera en 
”problemarea”. Om problemlösaren vill kan dessa problem skrivas som förklaringar och 
påståenden. 

För informationssystemets domäner kan dessa påståenden döljas, inte bara av luckor eller 
brist på information, utan också av associerade roller, ansvar, processer, funktioner, 
strukturer, kulturer och relationer. I andra domäner, beroende på vilken miljö som metoden 
fokuserar på, kan ändå luckor och brister uppstå p.g.a. socialgrupper, funktioner, 
produktionsproblem, dålig produktkvalité, etc. För att reda ut och förklara dessa utlåtanden 
måste problemlösaren ställa frågor av typen vad och varför och inte frågor av typen hur och 
vem (Jayaratna, 1994). 
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5. Ramverk för utvärdering 

Här redovisas det ramverk ska ligga till grund för respektive utvärderingsmetod före, under 
och efter varje steg i utvärderingsfasen och hela kapitlet är i princip baserat på Jayaratna 
(1994). Först presenteras villkor för användningen och därefter ges en kort introduktion för 
hur en effektiv utvärdering bör vara konstruerad. 


5.1 Villkor för användning av NI MS AD 

Ramverket NIMS AD är inte en mall som ska användas för bedömning av om en metod i olika 
steg följer en viss kartläggning jämfört med ramverkets steg. Ramverket ska istället användas 
för att ställa frågor till metoden om vilka element som används i vilken ordning och hur de 
riktas. Ramverket skall hjälpa den potentiella metodutövaren att formulera, och ställa frågor 
utifrån en kunskapsteoretiskplan. Ramverket begär av sin utövare ett resonabelt och medvetet 
tänkande vid en metods olika steg, relationer och dess aktiviteter. Vid användningen av 
ramverket bör utövaren tänka på följande: 

• Den komplexiteten som finns i den ”aktiva världen” och den begränsning som den 
mänskliga förmågan har att begripa all den komplexiteten. Vilket bidrar till att det inte 
finns en sådan rik modell som kan beskriva all den komplexiteten. Detta till defacto att 
metod - in - action kan anta en annan struktur dvs. en cyklisk, sekventiell eller iterativ. 
Därför måste metoden kontinuerligt examineras för den relevans som den är avsedd för. 

• Den dynamiska omgivning runt ”situationen av intresse” innebära att man som metod 
utövare behöver kommunicera och avlyssna de involverade i situationen. Detta för att 
säkra relevans och upprätthålla den valda metodens aktiviteter i situationen. 

• Den individuella ” mentala tankeskapelsen” självbehov och den skicklighet utövaren har 
att sända och ta emot information (mellanmänsklig) har en stor inverkan och är betydande 
för hur utövaren praktiserar metoden i situationen. 

• NIMSAD är ett konceptuellt ramverk. Dess element är konstruerade i olika skeden för att 
illustrera det rationella i det kompletta ramverket. Exempelvis om ett visst element ska 
inkluderas i ramverket. Hur som helst den ordningen av en konstruktion ska inte innebära 
att ramverket bara är relevant för att välja rätt metod eller anpassa sig till en liknande 
ordningen. 

• NIMSAD ramverk är inte en metod. Det kan endast bli en metod om användaren av 
ramverket beslutar att välja detta i ett skede av problemlösningsprocessen. Att skapa 
struktur där de valda stegen visas hur de ska utföras. Om fallet är så, då måste användaren 
verifiera för sig själv att det är den ordning som är den mest effektiva och lämpligaste för 
”situationen av intresse”. 

• För att ett ramverk eller metod ska bli användbar måste utövaren förbereds med ett 
kritiskttänkande och själv reflekterande. Detta ska inte bara gälla examinationen av 
utövarens ”mental tankeskapelsen” utan också influera utövarens problemlösningsprocess, 
men även av situationen i sin helhet. 
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Ramverket ska användas för diskussion om metodens rationella ordning, strukturer och 
aktiviteter, men även hur de det strukturerats för ”mänskliga - aktiviteter - system” ska tas 
upp för diskussion. Detta ger insikt för de mänskliga aktiviteterna i organisationen med 
”mjuka” systemmetod. 


5.2 Introduktion till ramverket 

Ingen problemlösningsprocess kan vara komplett utan att en utvärdering har utförts. Det är 
utvärderingen av problemlösningsprocessen som ser till att problemlösningen blir effektiv för 
”problemsituationen”, om det inte på något annat sätt framgår att ”problemet” har lösts 
framgångsrik. Trots denna viktiga utvärdering är det få metoder som lägger till detta steg i sin 
metod. 

För att utvärderingen ska bli effektiv bör den vara bra strukturerad. Ramverket NIMSAD har 
valt de tre elementen problemsituationen, problemlösningsprocessen och problemlösningen 
som grund för utvärderingen. Genom att göra så tas inte bara hänsyn till elementen (de som 
redan är relevant och behöver utvärderas för lärandet) utan också systemmiljön för ramverket 
dvs. sammankopplingen av elementen. Utvärderingen bör ge stöd åt dessa tre steg för 
ingripandet i utvärderingen och för att maximera utövarens ansträngning att vara effektivitet 
under ingripandet pga. den dynamiska miljön runt elementen. Men även efter ingripandet för 
att tillvara ta lärdom av de tre elementen. 

Det designade systemet påverkar utförande, lönsamhet, överlevnadsmöjlighet och tillväxt för 
organisationen. Därför är problemlösningen i organisationens kontext en ansvarsfull aktivitet, 
och inte något enkelt som kan verkställas genom ett antal metod steg. De metoder som 
erbjuder problemlösning måste medverka till med en effektiv omvandling av resultat för 
situationen. Den roll som ramverket har är att hjälpa till med frågor om metoden, om vad som 
ska transformeras, varför de ska transformeras, hur det ska hjälpa oss igång med 
transformerandet. Om metoden erbjuder en effektiv transformering, då måste den även tillåta 
en noggrann granskning, vilket det menas en kritiks utvärdering. 

Metodutövaren har ansvar för att frågorna lämpar sig att ställas till organisationen. Genom 
utövarens inblandning kan utövaren direkt eller indirekt påverka organisationens tillvaro för 
medarbetares, tillfredsställelse, arbetsvillkor, karriärs utvecklingsmöjligheter, relationer och 
många andra faktorer. Det som utövaren hoppas på i slutet är ändå en lyckad eller misslyckad 
tranformering av situationen, inte av metoden. Den svaghet som metoden kan ha måste 
övervinnas, antigen genom utövares egen ansträngning eller med hjälp av andra. När, och var 
kan man byta ut och ersätta element, med egna idéer? För att göra det behöver man mer 
kunskap om metodens bakgrund, dess syfte, steg, fordran, etc. 

Detta avsnitt är fullt av frågor men inga svar. Det kan vara en väldigt frustrerande och 
obehaglig upplevelse. Men det är bättre att utövaren känner frustration vid detta steg och 
utveckla sin egen intellektuella tankeprocess än vid trasformeringen av den ”aktiva världen”. 
Och därefter leta efter politiska rättfärdigande för att dölja sina misstag, brister och 
misslyckanden. Varje gång en fråga skapar frustration, så finns det inget givet svar, och varje 
en sådan fråga medför en betydande innebörd för den utövaren som designar systemet. Det är 
utövarens roll att finna svaren på dessa frågor och rättfärdiga sin klokhet och avskilja sin 
moraliska ställning från svaren som ges. 
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5.3 Utvärdering av problemsituationen 

Den här utvärderingen är förberedande av intresse för resultatet och av klientens intresse för 
”problemsituationen”. Förutsatt att klienten och problemägaren har samma anmodan till att 
sätta igång med problemlösningen. De är väl förberedda med resurser i form av tid. 
Utvärderaren har ett etiskt och moraliskt ansvar för att andra intressenters intressen 
framgångsrik ska bli lösta. Denna utvärdering kommer att göras i tre steg. 


5.3.1 Före åtgärdandet 

Här fastläggs den inledande situationen och klientens angelägenhet för detta. Den absolut 
viktigaste uppgiften är att förstå klientens bekymmer och förväntan. Ibland kan klienten 
antyda deras ”önskade tillstånd” men sedan förvänta sig att utövaren ska identifiera de 
relevanta delarna för de abstrakta systemen frambringar det ”önskade tillståndet”. Men för det 
mesta döljs det ”önskade tillståndet” väl för utövaren, men klienten förväntar ändå att 
utövaren både ska realisera och implementera det önskade systemet åt dem, utan deras 
medverkan. Med andra ord så kan klinten varken uttrycka eller definiera det abstrakta 
systemet, eller arbeta fram de ”önskade tillståndet”. Vilket gör situationen illa strukturerad. 

Utövaren bör sedan begrunda den relevans och validera klientens behov. Detta för att de 
väsentligaste och viktigaste behoven ska identifieras. Klinten kan vid tillfälle ge en klar bild 
över dem ”önskade tillståndet” och det abstrakta systemet, men det varar inte under någon 
längre tid. Utvärderaren bör därför granska klientens intresse för att etablera en förståelse för 
sina handlingar och få klientens engagemang. Desto mindre engagemang från utövarens sida 
desto mindre intresse för klienten att ändra de ”önskade tillståndet” härav det abstrakta 
systemet för projektet. 

Utvärderaren måste välja en metod för denna situation. Vissa av metoderna har redan en hel 
del som hjälper utövaren att hitta klientens handhavande, medan andra metoder stödjer 
utövaren att förbereda den uppgiften. För att utreda och matcha metoden till situationen 
behöver utövaren veta vad metoden begär för vetskap om situationen t.ex. syfte, strukturer, 
steg, logisk grund, mönster, teknik och kompetens. Organisationer är väldigt komplexa 
enheter och som utövare kan man inte förvänta sig att en metod kan erbjuda explicita 
struktureringar för utövarens tankar och aktioner alla dimensioner. Därför kan inte 
utvärderaren förvänta sig att klienten klart och tydligt kommer att tala om vad de kan och inte 
kan. Detta medför att utvärderaren måste värdera innebörden. För varje domän och aspekt 
som inte täcks av metoden behöver utvärderaren söka hjälp från andra källor eller inventera 
sin egen metods steg (Jayaratna, 1994). 


5.3.2 Under åtgärdandet 

Det spelar ingen roll vilken metod utvärderaren använder. Utvärderaren kan inte garantera att 
alla inblandade i situationen vill samarbeta eller stödja de steg som utvärderaren behöver för 
att identifiera och lösa ”problemet”. Utvärderaren behöver veta att klienten kommer att 
fortsätta att ge kommentar till projektet och support inblandning. Ibland kan karaktären på 
situationen ändras, därigenom tvingas utvärderaren modifiera metod stegen eller ändra sin 
handling. Dessa förändringar kan få konsekvenser utanför ”situation av intresse” (speciellt de 
valda element i ”aktiva världen” som inte är under kontroll av klienten eller metod utövaren). 
Hot mot organisationen utifrån kan t.ex. vara rationalisering, övertagande, sammanslagning, 
försäljning. 
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5.3.3 Efter åtgärdandet 

Detta är en av de viktigaste aspekter för utvärderandet. De behov som bör fram av olika skäl: 

1. För att fastställa om det designade systemet blev implementerat inom den gränsen av 
lösning, tid och ansträngning. Detta hjälper till att etablera en effektivitet för projektet 
managements uppgifter att säkerställa projektets genomförande. En lösning som inte är 
lämplig bidrar inte till att lösa ”problem” i den ”aktiva världen”. Till exempel, i kontexten 
för att utforma och implementera ett system för orderprocesser. Går det då att ifrågasättas 
om implementationen var komplett inom tid och kostnader utan begränsning för ”aktiva 
system” och vara till värde för organisationen. Visa projekt har orsakat förseningar för 
produktionen till den graden att den slutliga lösningen inte kan transformeras i 
”problemsituationen”. 

2. För att fastställa om de ”aktiva systemet” gör det som det ska göra dvs. huruvida finns 
kännetecken från det ”abstrakta systemet” realiserade. Detta etableras den effektivitet för 
att designa och implementeringsfas. Till exempel för kontexten för orderprocessen 
systemet så bemöts kundens behov och krav. En legitim fråga vara: ” Kan orderprocess 
systemets prestanda möta en jämn efterfrågan ( effektiv) från kunderna och operera inom 
resurs -kostnad förhållande ( effektivitet ) som påträffas i beskrivningen av abstrakta 
systemet? 

3. För att fastställa om ”problemet” har lösts. Det etablerar relevansen av dem ”abstrakta 
systemet” av ”problemsituationen”. Det hjälper också till att försäkra effektiviteten av 
problemformuleringens fasen av problemlösningsprocessen. Exempelvis om klienten 
(eller metod utövaren) har definierat en effektiv orderprocess av system och med hjälp av 
de abstrakta systemen vill uppnå lönsamhet (”önskade tillstånd”). Då skulle frågan här 
vara om ”tillstånd” nu har realiserats och om det faktiskt nåddes tack vare 
säljorderprocessen systemet. Naturligtvis, om detta utvärderas måste det vara meningsfullt 
för klintens behov och behöver vara berättigad över en period för verksamhet och 
utförande av dem ”aktiva system”. 


Om vi tar orderprocessen igen som exempel, så skulle då utvärderingen vara att utvärdera om 
orderprocessen bidrar till att lösa ”problemsituationen”. Men om ett IT-system exempelvis 
ska bidra till att effektivisera flödet av varor och fakturor. Men den rådande kultur som finns 
marknaden som försenar betalningarna. Därför kommer inte investeringen att lösa problemet 
av cash flow även om det förbättra distributionen av god och pappersarbetet. Det 
uppmärksammar ledningens bristande kunskapsarea för problemet. Att lösa fel ”problem” är 
en vanlig företeelse som äger rum på många områden. 

Sammanfattning av de tre nivåerna för klienternas tillfredsställelse så behöver nedanstående 
punkter utvärderas: 

• ”Systemet” har utvecklats och blivit funktionsdugligt ifråga om tid, kostnad och andra 
viktiga restriktioner (”modell system” har blivit ”aktions system” med restriktion och 
policy). Detta relaterar till projektledningen. 

• ”Systemet” gör vad de förväntas göra (”aktions system” verka planerat efter det ”abstrakta 
system”). Detta relaterar till operationsutförande av designat system. 
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• ”Systemet” har transformerat situationen (”aktions system” har visat sin relevans). Detta 
relaterar till problemlösningen. 

Dessa punkter visar den effektiv vad gäller problem formuleringsfasen. 

För utövarens kunskaper finns det ingen metod som ensam kan förbereda denna explicita 
utvärdering T.ex. utvärdering av relevant hjälp efter varje steg. Självklart om klienten eller 
metod utövaren inte har formulerat problemprocessen rigoröst eller lämplig ändrat det 
utsvävande ” önskade tillståndet”, då har relevansen för en lösning utvecklats med enorma 
kostnader och ingen effekt har kunnat etableras. Utvärdering är ett slags hjälp för att stödja 
och förbereda problemlösningens fasen. Men även förbättra och höja deras kompetens nivån 
(Jayaratna, 1994). 


5.4 Utvärderingen av metodutövaren 

Detta är en viktig del av utvärderingen men det rekommenderas inte i någon 
problemlösningsprocess eller metod. Den här utvärderingen kan hjälpa till att skapa förståelse 
för användarens svaghet och styrka. Den ska också identifiera behov i den meningen att 
användaren förbättrar sin kompetens. Ändå har väldigt få problemlösningsprocesser och 
metoder uppmärksamt dessa behov. Identifikation av kunskapsnivå är nödvändig och är en 
erfarenhet som skulle kunna erhållas av situationen. T.ex. självkritik och reflektions 
förberedande av författaren som efter inventeringen av den ”aktiva världen” konsekvent visar 
brist på politisk skicklighet och förnuftsbeslut. 

Genom att använda den ”mental tankskapelse” modellen kan speciella frågor ställas till 
utövaren före, efter och under ingripandet. T.ex. väldigt ofta är speciella frågor listade i slutet 
av ett kapitel, men dessa är inte fullständiga. Ramverket göra det möjligt att ställa dessa 
frågor, därför att de har en mycket vidare kontext än de valda metoderna. Svaret på dessa 
frågor kan göra utövaren mer effektiv och kompetent som problemlösare. 


5.5 Utvärderingen av metodens problemlösningsprocess 

Det är ingripandet av att fastställa metodens grad av hjälp och hur den tillhandahåller termer 
för modellen, koncept, teknik, strukturer, etc. 


5.5.1 Utvärdering av metod före ingripande 

Metoden tillhandahåller en problemlösningsprocess reflekteras av sin filosofiska 
upphovsmans synvidd. Upphovsmannens uppskattning utfärdas i den ”aktiva världen” och 
dennes egen framgångsrika erfarenhet. Utvärderingen för att examinera beslutet att använda 
metoden är rättfärdiga och huruvida användaren en potentiell metod utövare förstår strukturen 
och stegen som den filosofiska skaparen av metoden planerat. 

Många som är intresserad av problemlösning letar för specifika metoder som kan hjälpa dem 
igång med problemlösningsprocessen. Metoder erbjuder många tillvägagångssätt (genom 
deras filosofiska, struktur, steg och hur man förbereder dessa steg) att komma igång med 
problemlösningen. Hur som helst, någon examinering av metodens relevans att verkligen 
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använda deras kriterier för en problemlösning ges inte. Därför måste användaren förvärva 
denna kunskap innan valet av metod göras. 


5.5.2 Utvärdering av vald metod 

Denna process att välja en metod medför att utövaren redan har tolkat och ändrat den 
filosofiska formen, natur, struktur och steg för metoden. Detta kan vara medvetet eller 
omedvetet ansträngning. Den utvärderingen som examinerar skärpta ändringar eller 
tolkningar på den valda metoden och dessa ändringar ska tillämpas. Ändringar kan vara 
nödvändigt när kunskapen om ”problemsituationen” missbedömt användningen av metoden. 
Det är viktigt att notera att om metodens original ändras så måste även det utvärderas. Men 
även varför och orsaken ändringen ska utvärderas. Det är sedan effekten av den ändringen 
som utvärderas och examineras (Jayaratna, 1994). 


5.5.3 Utvärdering av vald metod i aktion 

Trots alla intention att välja ”rätt” metoden så kan ingen metod i original, eller anpassad form 
förväntas verka i den struktur enligt det som bestämts i förväg för en given situation. 
Organisationens där metoden är applicerad är inte ett laboratorium. Organisationens 
medlemmar har egna individuella och unika ”mentala strukturer” precis som utvärderaren har 
sina. Organisationens medlemmar försöker på alla sätt att skydda och stödja deras egna 
intressen. Vilket menas att möjligheten att följa en metods struktur och steg i en sådan 
situation är som att klättra uppför ett berg och samtidigt följa en rak linje. Det är möjligt att 
övervaka och definiera en metod och som i varje steg är baserad på författarens dignitet. Men 
av erfarenhet menar Jayaratna att dessa situationer modifieras en hel del informell 
modifikations för att ge en komplett struktur. Men genom att lyfta upp sådana frågor under 
förfarande så medvetande görs en förståelse och bidrar till att i förväg bestämma strukturen 
och stegen. Men även vilka steg och ändringar i strukturen som bör göras för den avsedda 
metoden i den ”aktiva världen” (Jayaratna, 1994). 

Denna utvärdering är självklar för effektiviteten för metod - in - action. Genom att ställa 
frågor i detta skede kan man få kunskap om ändringar som måste göras för praktiskt och 
politiskt svårigheter för situationen. T.ex. aktiviteter för klienten som förhindrar utvärderarens 
aktion för problemlösningen. 


5.5.4 Utvärdering av metod efter ingripandet 

Den här utvärderingen handlar om den anpassade/adoptera metoden av originalet och hur 
dessa har fungerat i praktiken. Fokus här är att samla in lärdom som kan sammanfattas av 
erfarenheter av att använda metoder. Det kan vara en fördel om metoden ska användas igen, 
och då i vilken situation och vad som bör ändras etc. Den utvärderingen är livsviktig för att 
utveckla kompetens för att använda metoder för problemlösning. 
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5.6 Specifika frågor om problemsituationen 

Så vilka specifika frågor ska ramverket bidra med angående ”problemsituationen ”? Dessa 
frågor är: 

Vem är klienten? Och vilken förståelse har den för ”problemsituationen” (En fråga som kan 
uppfattas som arrogant, men ändå är relevant och nödvändig att ställa.) Enligt Jayaratna visar 
erfarenhet att klienten inte har tänkt på det ”önskat tillstånd ” förrän de vill se en 
lösningspresentation. Är dessa problem uppenbara? Vilken grad av engagemang har klienten 
för att se genom och att realisera utövarens lösningsförslag på problemet? 

Hjälper metoden till att identifiera problemägaren? Hur hjälper den utövaren att hjälpa 
problemägaren i problemlösningsprocessen? Vad är innebörden av en sådan aktion? Hjälper 
metod utövaren att fastställa den legitima av klientens intressen? Hur hjälper metoden till och 
fastställa klientens förståelse för att kommunicera sina behov? Om inte, godkänner metoden 
klientens behov vid startpunkten? Om dessa behov inte hjälper till att lösa klientens problem? 
Kan metoden då hjälpa till att identifiera dessa? 

I vilka typer av situationer är metoden utövarens fasadbeklädnad? Är situationen väl, mindre 
eller illa strukturerad? Hur är metodutövarens förståelse för omgivningen av situationen? 
Vilken typ av situation gör metoden krav på för att vara ändamålsenlig? Gör den några 
kommentarer om situationen överhuvudtaget? Eller, fordras det, eller kan inget trasformeras 
av situationen? Är dess fordran tillfredsställande? Vilka bevis och förklaringar erbjuds? 

Vad efterfrågar situationen - för att identifiera ”problemet” eller för att designa en lösning för 
identifierat problem? Eller för att implementera en redan designad lösning? Eller för alla tre? I 
denna kontext, vad har metoden för syfte? Vad görs anspråk på? Är fordran rättfärdig? 

Vilken typ av kultur och politik dominerar situationen? Vilken ledningsstil - medverkande 
eller auktoritativ? Vad rekommenderar metoden för denna typ av stil? Kan denna 
rekommendation praktiseras på situationen? Om inte vad består komplikationen av? Vilket 
risktagande har metod utövaren gjort när denna metod valdes? Vilket ytterligare behov 
behövs från utsidan av metoden för att adressera dessa? 

Vilken typ av ”verklighet” har klienten och andra intressenter varseblivet? Vad är deras 
bedömning av den ”verklighet” för situationen? Vilken filosofisk vy stödjer metoden eller har 
förståelse för ”verklighet”? Hur matchar vyn situationen? Vad är innebörden för dessa vyer? 

Vilken iakttagelseförmåga är dominerande för problemsituationen? Är de uttalade i tekniska, 
politiska, social, kulturella eller funktionell termer eller är det en mix av dessa? 


5.6.1 Specifika frågor om metodutövaren 

Vilka specifika frågor kan ställas till metod utövaren? 

Vad är metod utövarens ”värdesatts” Vad tror utövaren är det ”goda”? Exempelvis vilka av de 
ekonomiska, politiska, sociala, kulturella eller tekniska värden tar metod utövaren mest 
hänsyn till? Hur engagerande är dessa värden? Kan dessa uppoffras i en situation för 
personalens behov? I denna kontext, vilka värden rekommenderar metoden? Hur 
överensstämmande är det med metod utövarens värderingar? T.ex. om metoden 
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rekommenderar sociala värden och metod utövaren antar ett politiskt värde hur säkerställs och 
åstadkommer då det ”trovärdiga” deltagandet av metoden? I denna kontext kan metoden 
användas för den egna kontrollen som fordras för att säkerställa andras medverkande. Metod 
utövaren kan då anpassa metodens steg och strukturering för att passa egna behov. Här har 
man det första indikationen på en förändring av metodens steg och hur utövaren kan ersätta 
eller ignorerar metodens steg i situationens särdrag (Jayaratna, 1994). 

Vad är etiskt uppförande? Har metoden något etiskt fastställd norm? Visar den hur detta kan 
upprätthållas? Om det finns etiska normer i metoden, hur matchar de metod utövarens egna 
normer? Jayaratna vet av egna erfarenheter att detta skapar stora diskussioner bland de 
inblandade i situationen, och för metod utövaren i den givna situationen. Kan etisk handlande 
diskuteras avskilt, och vad ska överlämnas åt metod utövaren. Metodens roll är att bidra med 
ett medvetet tänkande för metod utövaren och erbjuder hjälp till att lösa konflikter. 

Vilken nivå av abstrakt och tekniskt tänkande kräver metoden från sin utövare innan den kan 
utövas? Eller kan metoden operera på vilken nivå som helst, för vem som helst? Kan metod 
utövaren var den samma som arbetar i produktionen? 

Hur förespråkar metoden att den filosofiska vyn ska matcha utövarens filosofiska vy? Vilken 
konsekvens får detta mischmasch? 

Vilken kunskap och skicklighet måste metods utövare behärska? Vilken kunskap och 
skicklighet förväntas av utövaren innan utövaren kan bli en effektiv användare av metoden. 
T.ex. en del metoder kräver användaremedverkan från olika delar av organisationen. Det är 
önskvärt och praktiskt att skapa en förståelse mellan politik och erfarenhet. Försök att öppna 
upp omgivningen med fritt flöde av kommunikationskanaler där det redan nu är begränsad. 
Går det att lyfta upp en rad av mellanmänskliga och emotionella svårigheter för metod 
utövaren. Vilken hjälp kan metoden erbjuda till utövaren att förvaltande dessa svårigheter, om 
dessa finns? 

Vilket motiv har metod utövaren? Bara inträdet till metodens utövare för situation kan redan 
ha givit en chans till förståelse för hur personliga behov tillfredsställs. Fenomenologi baserade 
metoder kan hjälpa dess utövare med en potentiell styrka för att utmana under kontroll där 
deras aktioner kan övervakas och begränsas. Medan tillämpningen av en vetenskaplig 
baserade metod också kan ge samma nivå av kontroll av utövaren och kunskap genom att 
praktisera kunskap, designskicklighet och tekniks know-how. 

Ramverket hjälper utövaren att examinera så problemet faktiskt blir löst. Vilken modell och 
ramverk erbjuder metoden för en situation? Vilken modell behöver metod utövaren för att 
hantera situationen? Jayaratna har funnit ut att det flera modeller erbjuder är helt otillräckligt 
för att förstå situationen. 

Vilken nivå av erfarenhet behöver metod utövaren ha? Kan det hjälpa även om utövaren inte 
har domänkunskap där ”problemsituationen” finns? Om det är så, hur hjälper metod utövaren 
till att generera en lösning? 

Vilken roll förväntar sig metod att utövaren har, t.ex. en expertroll eller rådgivande? Vad 
kännetecknar denna roll? Vad är konsekvens för metoden att den har dessa rollkaraktärer? 
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5.7 Specifika frågor om metod 

Vilka frågor kan ställas om metoden i de olika stegen. 

5.7.1 Förstå en situation av intresse 

Den första frågan är vilken specifikation bistår metoden för att skapa gränslinjekonstruktion? 
Litar metoden på utövarens förmåga att definiera ”gränslinje av intresse” och därmed att 
identifiera ”situationen av intresse”? Om inte, hjälper den då utövaren att välja eller utesluta 
ur situationen? Vilka kriterier erbjuds i denna process? Vad är innebörden för detta val eller 
uteslutande för utövaren? Många metoder uppmärksammar inte utövaren på gränsdragningen 
i situationen, vilket kan ge en kännbar konsekvens (Jayaratna, 1994). 

Vilken roll har klienten för respekt metoden? Känns den inbegripande och/eller medverkande 
av klienten? Eller behandlas klinten som en yttre företeelser av metoden? Medverkar metoden 
till att klienten och utövare samarbetar för att komma underfund med situationen? Eller 
accepterar metoden åsidosättande och auktoritet av kunden i problemformuleringen? 

Hjälper metoden utövaren att identifiera källor till information, t.ex. vilka källor är de mest 
relevanta för användbar information? Tillhandahåller metoden någon kritik av valda källor. 
Diskuteras några särskilda metoder? Rekommenderas några andra vägar som kan vara mer 
lämplig av filosofisk natur av metoden? Ska dessa följas i varje situation? 

Vilken skicklighet framhävs som relevant och användbar i detta uppförande steg? Är det 
explicit om detta? Förvarnar det användaren om detta behov av skicklighet? 


5.7.2 Förbered en diagnos 

Vilket modelleringsbegrepp och tekniker erbjuder metoden för att uttrycka situationens 
kännetecken? I vilken utsträckning är dessa begränsade eller hjälpande? Kan all information 
uttryckas noggrant? Vad händer med den informationen som inte modellens teknik kan ta 
hand om? Hur kan detta bibehållas i metod utövarens minne? Eller uttrycks det med egen 
teknik? Om det uttrycks med egen teknik hur kan denna information läggas till eller länkas till 
det formella uttrycket av metodanvändningen? 

Vilken nivå på uttryck rekommenderar metoden? Är det konceptuell/logisk uttryck? Eller är 
det en naturvetenskaplig uttryckssätt? Särskiljer metoden på dessa två olika nivåer eller 
kombineras dessa? Vilken ledning erbjuds för att konstruera uttryck? Eller är det en uppgift 
lämnad till metod utövaren? Vad är konsekvensen av vad för de för följande steg av metoden? 

Vilken information är fångad i omgivning (kontext) eller uttryckt? Uttrycks det tillräckligt för 
att förstå den ”aktiva världen”? Kan detta användas från och med nu som en bas för 
problemlösningen? Behöver uttrycket uppdateras, om så hur ofta behöver det uppdateras för 
att vara representativt för situationen? Uppmärksammar metoden utövaren när det behöver 
uppdateras? 

Vilka verktyg och tekniker finns tillgängliga för uttrycket? Är dessa verktyg oberoende eller 
när länkade till metoden? Influerar tekniken den information som fångas för situationen, t.ex. 
istället för enkelt teknik för insamling av redan insamlad information? 
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Föregående frågor om beskrivning av ”situation av intresse” är de viktigaste frågorna ”hur 
formuleras dessa i form av att tillhandahålla duglig information av ”situation av intresse”? 
Kan dessa stå för sig själv och få det absoluta ”tillstånd” av ”situation av intresse”? Är 
tillvägagångssättet pålitlig och kan det baseras på följande steg i metoden? 

Om klienten och andra deltagare är överens om formuleringen hur svara metod utövaren? 
Vilken vägledning erbjuder metoden? Är dessa frågor pragmatiska för metod utövaren så svar 
kan hittas från utsidan av metoden? 


5.7.3 Definiera plan för en prognos 

Kan metod erbjuda någon hjälp att definiera denna prognos? Om inte, vi lk et ”önskat tillstånd” 
accepteras som legitimt? Är det fler än ett och hur hjälper metoden till att lösa skillnaderna? 
Om metoden inte hjälper att utföra detta steg, vilka kriterier erbjuds för att etablera en 
välgrundat ”önskat tillstånd”. Uppmärksammar metod utövaren på detta steg överhuvudtaget? 
Om den inte gör detta vad återstå då för metod utövaren att fastlägga de ”önskat tillstånd”. 
Vad blir konsekvens när metoden inte medverkar i denna uppgift? I vissa fall är inte kl ienten 
inte själva klara med det ”önskat tillstånd”. 


5.7.4 Definiera problem 

Vilka ”problem” eller problemtyper är metoden intresse av? Vilka kriterier tillhandahåller 
metoden för att definiera ”problem”? Hur hjälper metod utövaren att erhålla 
”problemförklaring”? Självfallet om det misslyckas att förvissa sig om att det tas hänsyn till 
det ”önskat tillstånd”, då blir det inte heller några problemdefinitioner. I detta fall hur kan 
metoden hjälpa utövaren att förvissa sig om ”problem” eller utvärdera tillstånd 
”problemförklaring”. Eller hjälper till att undvika dessa helt och hållet? Vissa metoder 
tillhandahåller endast hjälpmedel för att samla in ”problem” utan att fråga - men inga frågor 
som är lämpade för klienternas klarläggning (Jayaratna, 1994). 
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6. Beskrivning av de fyra utvärderingsmetoderna 

/ detta kapitel ges en beskrivning av de tänkta utvärderingsmetoderna. Kapitlet börjar med en 
introduktion om vad processmodellering är och vilka olika synsätt det finns, därefter hur man 
hittar och definierar processer. En redogörelse görs för hur processerna uppritas enligt 
IRM:s metod. Vidare beskrivs handlingsbara IT-system som ligger till grund för mål- och 
kriteriebaserad utvärdering. Till sist ges en inblick i vilka ekonomiska aspekter som ligger till 
grund för utvärderingsmetoden kostnad - nytto - analys. 


6.1 När används processmodellering 

Processer beskriver vad som utförs i verksamheten och hur detta ska utföras genom att 
metoden processmodellering används för att skapa en kund- och resultatfokusering tvärs 
igenom hela organisationen. Exempelvis vid verksamhetsutveckling där man vill förändra 
processerna för att svara bättre mot kund och marknadskrav, vid 

sammanläggning/uppdelningen av verksamheter eller vid planering och genomförande av ett 
IT - projekt. Applikationsprocessen kallas den sistnämnda och består av arkitektur- och 
kravspecifikation samt realiseringsprocesserna (IRM, 2004). 

I arkitekturprocessen handlar det först och främsta om att identifiera verksamhetens 
affärsprocess. En verksamhet består i normalt fall av 10-15 affärsprocesser. Genom att ta fram 
en övergripande processkarta som beskriver affärsprocessernas och samband mellan dem. 
Därefter tas en översikt över hur befintliga system och databaser idag stödjer verksamhetens 
processer. Arbetet dokumenteras i en plan som utgör en målbild för det bästa sättet att förutse 
processerna med kvalitetssäkrad information (Ibid.). 

Med den framarbetade planen som utgångspunkt planeras vilka system och databaser som på 
ett lämpligt sätt ska avvecklas i takt med de nya system och databaser som utvecklas. Målet är 
att anskaffa IT-stöd som ger verksamhetens processer tillgång till nödvändig information av 
rätt kvalitet. Verksamhetens styrdokument för informationsförsörjning är den utarbetade 
planen och utvecklings-, avvecklingsplanen (UA-planen) (Ibid.). 

I kravspecifikationsprocessen avgränsar man uppdraget med hjälp av resultatet från den 
utarbetade planen och UA-planen. Beskrivningen av de processer som ingår i avgränsningen 
fördjupas och kompletteras. Olika åtgärdsförslag och beskrivningar tas fram för att uppnå 
förväntade effekter. Processer stäms av mot framtagna förändringsmål, kritiska 
framgångsfaktorer och problem (Ibid.). 

Det finns olika sätt att rita processer på. Jag har valt att använda och beskriva IRM AB:s 
tillvägagångssätt. 


6.2 Olika processyner 

I den modema litteraturen kring processtänkande kan man urskilja två olika syner på hur 
process identifieras. Den transformationsorienterade och den kommunikationsorienterade. 

”Keen & Kapp(1996) skiljer mellan ”process as a workflow” och ”process as the coordination 
of work”. En liknande distinktion görs av Ljunberg (1997) som skiljer mellan en 
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arbetsflödessyn (eng. workflow) och en kommunikationssyn (eng. work as communication) 
på process. ”Consider how much of an ordinary work day that is devoted to informing others, 
collecting information, questioning, arguing, deciding, negotiating, promising” (Lind, s 129. 
2001 ). 

Den transformationsorienterade synen på processen 

Att uppfatta processer som transformation innebär att processers värdeökande aktiviteter är i 
fokus, där värdeökningen syftar till att tillfredsställa verksamhetens kund. Input transformeras 
till output. 

Lind påpekar att Ishikawa 1995 påtalade hur viktigt det är att orientera sig mot 
konsumenterna och inte mot producenterna. Detta för att kvalitet bör sättas i det första 
rummet. Kvalitetsområdet (TQM) är ett annat område inom vilket en 
transformationsorienterad syn har haft stor genomslagskraft. För att säkerställa kvaliteten i 
processen och produkten används processledningen. Kvalitet uppnås genom ständiga 
förbättringar av verksamhetens processer, varför mätning och återkoppling är centralt (Lind, 
2001 ). 


6.3 Processmodellering 

Att fokusera på processerna innebär att uppmärksamheten förskjuts från de färdiga resultaten 
som produkter och tjänster till de aktivitetskedjor som formar dem. Processfokusering leder 
vidare till frågeställningen: ”vem gör vad”. Den grundläggande tanken är att processen skapar 
resultat och därför är det i första hand den som bör styras och förbättras. Och så länge det 
finns variation i processen kommer också resultat att variera. Vikten att fokusera på processer 
är långt ifrån någon ny insikt inom kvalitetsområde. Redan på 1930-talet hade Walter A 
Shewharts idéer om kvalitetsstyrningens ändrade inriktning på kvalitetsområdet från att 
högkvalitativa produkter skulle åstadkommas genom omfattade slutkontroller, till att istället 
göra detta genom styrning av processerna (Ljungberg & Larsson, 2001). 

All verksamhet sker i processer och en del av dessa leder fram till varor och tjänster som 
organisationen tillhandahåller till sina externa/interna kunder. Processer behöver vara dugliga 
och effektiva och de skall dessutom styras så de ger önskad kvalitet (Sandholm, 2001). 
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6.4 Processorientering 

Traditionellt är verksamheten organiserad med avseende på specialiserade funktioner som 
produktutveckling, inköp, produktion, marknadsföring och service (se figurl2). 

FUNKTIONER 



Figur 12, Funktionell organisation (Sandholm, 2001) 


Arbete med varor och tjänster följer oftast flöden som går på tvären genom funktionella 
organisationer se figur 13. Samma flöden gäller av information och kommunikationer. 
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Figur 13, Funktionell organisation med tvärfunktionella flöden (Sandholm, 2001) 


6.5 Vad är en Process 

"En process är ett nätverk av aktiviteter som upprepas i tiden och vars syfte är att skapa 
värde åt någon extern eller intern kund "(Bergman & Klefsjö, 2001, s.416) 

o 

Kännetecken för en process( Information Resource Management AB, 2003;SIQ Institutet för 
Kvalitetsutveckling, 2004): 

'T Den har kunder, dvs det finns en mottagare av processens resultat 
'T De korsar organisatoriska gränser, internt mellan olika funktioner och/eller mellan 
verksamheter som samarbetar i ett kund- och leverantörsförhållande 
'T De är oftast namnlösa - det finns t ex ingen avdelning för ”expediering av order” 

•S De upprepas flera gånger 

'T De kan enkelt förändras genom att man tar bort eller lägger till aktiviteter 
'T De är avgränsade genom att ha en väldefinierad början och ett precist slut kopplat till ett 
resultat 

•S De använder verksamhetens resurser (information, arbetstid, råvaror) och omvandlar dessa 
till nytta för kunden 

•S En process utförs inte alltid på det mest effektiva sättet och vid översyn/effektiviseringar 
tas sällan ett helhetsgrepp. Många gånger ser man endast till enskilda delar av processen, t 
ex en aktivitet som effektiviseras genom datorisering, istället för att analysera hela 
processen. Det finns många orsaker till att processer ser ut som de gör. De kan påverkas 
av organisations- och teknikförändringar eller av att nya produkter införs, etc. Genom att 


3 Föreläsningsmaterial på kursen Kravspecifikation för IT-system som hölls av IRM AB 
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analysera hela processen kan man ofta med relativt enkla medel, och genom att använda 
modern informationsteknik, få väsentligt effektivare arbetsflöden. 


6.6. Processkategorisering 
6.6.1 Huvudprocess 

Ljungberg m.fl.(2001), Sandholm, (2001) använder definitionen Huvudprocess medan 
Rentzhog (1998) använder benämningen Kämprocess. Någon entydig definition på begreppet 
huvudprocess finns inte, utan istället kan man tvingas använda flera beskrivningar som 
kompletterar varandra. Huvudprocessen kan beskrivas enligt Ljungberg m.fl., 2001, s.82: 

• De processer vars aktiviteter förädlar varor och tjänster till en extern kund. 

SIQs modell för verksamhetsutveckling och därmed Utmärkelsen Svensk Kvalitet använder 
denna definition. Beskrivningen framhäver den externa kundens centrala roll för 
verksamheten. Den inkluderar flertalet av en verksamhets viktigaste processer men inte alla. 
Processen ”att utveckla nya produkter” som i vanliga fall endaste har interna kunder, men 
likväl borde ses om en huvudprocess, i utvecklingsföretag. Att påstå att exempelvis Volvo 
Personvagnar, Astra Zenecas eller Microsofts produktutvecklingsprocesser inte är 
huvudprocesser verkar nog konstig för de flesta. Definitionen utesluter helt enkelt de centrala 
delar av en organisation som direkt levererar till en extern kund. Den ovan nämnda 
definitionen räcker inte. Man kompletterar med följande beskrivning Ljungberg & Larsson, 
2001, s.82: 

• Processer som realiserar affärs-/verksamhetsidén. 

För att förverkliga verksamhetens affärsidé kärvs en uppsättning processer och dessa ska bli 
avgörande för framgångarna. Beskrivningen huvudprocesskartan visar den kombination av 
processer som ur ett kundperspektiv utgör verksamhetens kärna. Man kan lägga till ytterligare 
en beskrivning av huvudprocesser menar Ljungberg & Larsson, 2001, s.83: 

• Processerna som tillsammans bildar ett system som utgör grunden för verksamheten. Om 
en tas bort faller verksamheten. 

Detta kan ses om en ytterligare en definition och baseras på ett systemtänkande. 
Huvudprocesserna ses som organisationens själ vilket utesluter en del processer som i och för 
sig kan vara kritiska för verksamheten. Ett system är beroende av alla sina komponenter och 
det innebär att alla är lika viktiga. Exempelvis processen ”att ta betalt av kunderna” är en 
process som om den inte fungerar skulle fälla hela verksamheten på sikt eftersom inga pengar 
skulle flyta in. Men det är troligt att denna process är en förklaring på vad huvudprocess är 
därför skulle kunna vara enligt Ljungberg & Larsson, 2001, s.83: 

• Processer av speciell betydelse för verksamheten. 
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6.6.2 Stödprocesser 

Stödprocesser behövs för att huvudprocesserna ska fingera så bra som möjligt. 
Stödprocessema ska värderas utifrån hur väl de förmår stödja huvudprocesserna och ska 
därför inte tillskrivs något egentligen värd. Exempel på vanliga stödprocesser är fakturera 
kunder, bemanna verksamheten, skapa budget, skapa prognoser, planera produktion, 
underhålla utrusning och göra bokslut (Ljungberg & Larsson, 2001). 


6.6.3 Ledningsprocesser 

Ledningsprocesser behövs för att styra och samordna huvud- och stödprocessema. Många 
ledare har svårt att se hur deras arbete skulle kunna beskriva som en strukturerad process. Ett 
tänkbart motiv kan vara att man inte fullt ut har tänkt igenom vad det innebär att leda en 
verksamhet. Möjligtvis tycker de att det egna arbetar är för komplicerat att kunna karläggas 
och beskrivas som en process. Eller så går ledarens arbetstid åt att var behjälplig för att lösa 
diverse problem som uppstår i den dagliga verksamheten. Det blir således inte mycket tid kvar 
att ägna åt verksamhetens processer (Ibid.). 


6.7 Processmodellens kundbegrepp 

Bergman & Klefsjö (1995); SIQs modell, (2004) har följande kundbegrepp ”de som 
verksamheten vill skapa värde för”. Kunderna kan vara personer eller organisationer. De kan 
finnas utanför organisationen - externa kunder eller inom organisationen - interna kunder. 
Vem som är kund kan vara situationsanpassat och kunderna kan ha olika benämningar olika 
verksamheter, till exempel brukare konsumenter, beställare, patienter, elever klienter. 


6.8 Kartläggning av processer 

Först identifieras affärsprocesserna och man gör en prioritering av vilka processer som man 
ska arbeta vidare med. Det finns olika sätt att finna processer på: 


1. Lista kunder 

2. Lista resultat 

3. Identifiera starthändelser 

4. Rita in områden i processkaran 

5. Bestäm antal processer i processkartan 

6. Modellera processerna 


Vid dokumentationen av processerna har jag valt att använda IRMs (Information Recourse 
Management AB) ritningsmetod istället för det vanliga flödesschemat. Processerna 
dokumenteras i en processkara. Strecken mellan affärsprocesserna visar att det finns ett 
samband, men inte vilken typ av samband (se figur 14). 
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Produkt 

tillgänglig 


6.8.1 Agenda för processmodellering 

Det bör vara 10 - 12 deltagare i form av verksamhetskunniga, projekt/planeringsansvariga, 
processägare, verksamhetsutvecklare och två handledare enligt IRM, (2004). Sandholm 
(2001) menar att det är sällsynt att endast en person har tillräckliga kunskaper för att kartlägga 
alla aktiviteter i en process. Därför bör uppgiften ges till en grupp där det ingår personer med 
detaljerade kunskaper om varje del av processen. De som verkligen har detaljerade kunskaper 
och känner processen bäst är de som arbetar i processen. Därför är det viktigt att dessa är med 
i arbetet. 


6.8.2 Modellera processerna 

1. Identifiera händelserna som startar processen 

2. Identifiera kund och resultat som avslutar processen 

3. Beskriva och namnsätta aktiviteterna i den ordning de normalt utförs i processen 

4. Anteckna kommentarer till aktiviteterna 

5. Skriva vem som utför och var i organisationen arbetet utförs 

6. Numrera alla aktiviteter 

7. Gör en detaljerad beskrivning av aktiviteterna 


Identifiera händelser som startar processen 

Ofta kallas den händelse som initierar processerna eller aktiviteterna för trigger. Man ska inte 
beskriva vilken information eller vilket material som kommer in i processen, utan den 
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händelse som startar händelsen som startar processen. Både starthändelser och resultat ska 
vara tydliga och mätbara. Det är en förutsättningen för att man ska kunna veta om processen 
fungerar bra eller dåligt (IRM, 2004). 


Exempel: 

En kund lämnar en förfrågan per telefon. Till vänster om starsymbolen skriver man in 
händelsen som startar processen. 




Förfrågan 
från kund 


Material 
levererat 
till kund 



Identifiera kund och resultat som avslutar processen' 

Man tar reda på vem/vad som är kund till processen samt processens resultat. Detta skriver 
man sedan efter slutsymbolen (Ibid.). 


Beskriva och namnsätta aktiviteterna i den ordningen de normalt utförs i processen 

Alla aktiviteter som finns i processen ska hittas, dvs. vad som behöver utföras från 
starthändelsen till dess att resultatet är uppnått. Namnet ska beskrivas som en kortare 
beskrivning av aktiviteterna och skrivas i boxen. Placera aktiviteterna i den ordningen de 
normalt utförs. Aktiviteterna förbindas med ett streck som visar flödet i processen (Ibid.). 



Förfrågan 
från kund 



Telefonist Telefonist Truckförare Ekonom 

Kundtjänst Kundtjänst Spedition Ekonomiavd 



Skriv vem som utför och var i organisationen arbetet utförs 

Under varje box skriver man vem som utför aktiviteten och var i organisationen detta sker. 
Aktiviteten kan vara manuell eller datoriserad men den ska ändå dokumenteras. Detta görs för 
att studera flödet i processen är komplext och berör många ol ik a i organisationsenheter (Ibid.). 



Numrera alla aktiviteten, 

Alla aktiviteter får ett nummer i processen. En detaljerad beskrivning av aktiviteterna i form 
av löptext för att förtydliga vad som utförs inom ramen för aktiviteten. Beskrivningen ska 
även innehålla information om aktivitetens resultat (Ibid.). 
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Olika nivåer på processen 

Affärsprocessen kallas de processer som beskriver verksamheten på en övergripande nivå. En 
affärsprocess består av antal processer som tillsammans skapar ett mervärde som kunden kan 
uppfatta. Processerna ritas med den fiskliknade symbolen . En affärsprocess kan beskrivas i 
flera nivåer och det genom att affärsprocessen delas in i flera processer som beskrivs i 
processkartor (Ibid.). 


Nivå 1 



Nivå 2 



När man detaljerar processer beskriver man de aktiviteterna som ingår i processen. Dessa 
aktiviteter hänger samman och ritas som boxar på en linje. Vid många aktivtetrar går linjen 
över flera rader, dock ska aktiviteterna placeras i stigande ordning från vänster till höger 
(IRM, 2004). 


Förfrågan 
från kund 


12 3 4 



Kundtjänst Kundtjänst Kundtjänst Kundtjänst 


Syntax processkarta 

Symbol för process. Processens namn skrivs 
inuit med versaler. Processens nummer 
skrivs i en textruta ovanför. 

8 

Process- 

/ namn / 

/ / 

Linje som visar avvikelser från huvudflödet. 

\ \ „ 

2 / 


65 








Beskrivning av de fyra utvärderingsmetoderna 


Överhop : Ibland utförs inte en aktivitet, detta 
visas med en pil som går förbi en aktivitet. 


Repetion: Aktiviteter kan utföras flera gånger 
innan flödet går vidare i processen. 


Valtsituation/parallella aktiviteter: 

Det finns många processer som utförsparallet 
och då uppstår alternativa vägar i processen. 


6.9 Handlingsbara IT-system 

Det traditionella sättet att se på IT-system är strikt beskrivande och innebär att utvecklare ser 
IT-system som en avbild av verkligheten representerad i en databas. Ur ett handlingsorienterat 
perspektiv ses IT-system som ett kommunikationssystem och betonar vad användare gör vid 
kommunikation via systemet. Ur detta perspektiv ses IT-system som teknikförmedlad 
verksamhetskommunikation vilket innebär att handlingar som är kommunikativa och tolkande 
utförs med hjälp av IT-systemet (Ibid.). 

Från det handlingsorienterade perspektivet menas att IT-system har en handlingsförmåga och 
därför är handlingsbara. Ett IT-system som anses handlingsbart består av Cronholm et al., 
2003: 

• En repertoar av handlingar möjliga att utföra 

• Handlingar utförda via interaktion mellan användare och IT-system samt automatiskt av 
IT-systemet 

• Ett minne innehållande alla utförda handlingar och deras förutsättningar 

• Dokument som förutsättning, media och resultat av handlingar 

• Ett strukturerat verksamhetsspråk som sätter ramar för handlingar, minne och dokument. 
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6.9.1 Kvalitetsideal 

Cronholm & Goldkuhl, (2003) har utvecklat ett antal kvalitetsideal och värderingskriterier för 
att utveckla och fastställa om ett IT-system är handlingsbart. Dessa kvalitetsideal är: 

1. Kan enkelt förstås vad som kan göras med systemet (tydlig handlingsrepertoar) 

Detta kvalitetsideal handlar om att IT-systemet på ett tydligt och begripligt sätt visar den 
handlingsrepertoar som erbjuds, det vill säga vilka verksamhetshandlingar som kan utföras i 
en given situation. IT-systemet ska tydligt informera om vilken typ av handling som erbjuds 
och om det är det en läs-, uppdaterings- eller registreringshandling. Ett exempel som bidrar 
till ett förtydligande är att använda det språkbruk som normalt förekommer i verksamheten 
(Ibid.). 

2. Kan ”sägas” det man vill genom systemet (tillgodose kommunikationsbehov) 

Detta kvalitetsideal framhäver att IT-system används för att kommunicera med andra i 
verksamheten och att detta kommunikationsbehov ska tillgodoses genom IT-systemet. Det ska 
finnas möjligheter, genom olika fördefinierade fält, att registrera olika uppgifter i systemet 
som man önskar att andra personer skall bli informerade om. Dessa registrerade uppgifter blir 
ofta sparade i IT-systemets handlingsminne för att sedan bli kommunicerade till mottagare 
(Ibid.). 

3. Kan enkelt ta sig till önskad plats i systemet (lättnavigerbar) 

Kvalitetsidealet innebär att ge stöd för navigering i IT-systemet där önskad 
verksamhetshandling kan utföras. Verksamhetshandlingen kan till exempel innebära att 
användaren vill utföra en registrering eller enbart söka information om något. 
Navigeringsstödet skall ge enkelt stöd oberoende av IT-systemets struktur. Det finns flera 
typer av navigering. Hierarkisk navigering som innebär en förflyttning till närmast högre eller 
lägre nivå i IT-systemet. Det finns också sekventiell navigering som innebär en förflyttning 
inom samma nivå. En tredje typ är direkt navigering som innebär en förflyttning till en 
användningssituation lokaliserad var som helst i IT-systemet. För att användaren ska kunna 
orientera sig och enkelt kunna lokalisera var i IT-systemet en verksamhetshandling kan 
utföras bör en spårbarhet av navigeringen visas (Ibid.). 

4. Förstå konsekvenserna av föreslagna och utförda handlingar (handlingstransparent) 
IT-system reagerar på användarens verksamhetshandlingar genom att utföra en 
systemhandling. T ex 1. Vad kan jag göras?, 2. Nu gör jag det (utförandet)!, 3. Datorns 
reaktion!, 4. Vad har gjorts (tolkning/eftervärdering)? En verksamhetshandling kan innebära 
en begäran om förändring av handling sminnet. IT-systemets handling innebär att 
handlingsminnet (databasen) förändras. IT-systemet skall vara utformats så att användaren i 
förväg förstår att verksamhetshandlingen innebär att handlingsminnet förändras. IT-systemet 
skall i också i efterhand ge en bekräftelse på att handlingsminnet förändrats. Till exempel kan 
IT-systemet ge ett meddelande eller förändra innehållet av den aktuella skärmdokumentet som 
gör att användaren förstår att handlingsminnet har förändrats.(Ibid.) 

5. Direkt se att det man försökt göra blev gjort (feedback) 

IT-systemet skall alltid ge ett begripligt svar på en utförd verksamhetshandling. Svaret kan 
bestå av en beskrivning av vad IT-systemet gjort och på vilket sätt stödja användarens 
tolkning av vad som skett. Konsekvenser och utförda handlingar skall kunna förstås av 
användaren. Feedback skall ges för navigeringshandlingar, detta sker naturligen genom att 
systemet utför förflyttningar till annan plats i systemet. Ett sätt att stödja feedback i samband 
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med navigering är att tydligt rubricera varje dokument. På så sätt kan användaren få 
omedelbar bekräftelse på om navigering har lyckats eller ej (Ibid.). 

6. Enkelt få hjälp att veta vad som gjorts (tydligt och lättåtkomligt handlingsminne) 

Tidigare lagrad information skall vara lättillgänglig. Information om tidigare utförda 
handlingar skall vara lätt att komma åt. Handligsminnet kan bestå av både historisk 
information, alltså tidigare utförda handlingar och förväntade handlingar (handlingar som bör 
utföras) (Ibid.). 

7. Vet vem som ”sagt” vad (personifiering) 

I kommunikationsintensiva verksamheter skall IT-systemet hålla reda på vem som har sagt 
vad. IT-systemet skall vara aktörstydligt. Ofta finns det behov att få reda på mer information 
än den som tillhandahålls av IT-system. Det kan finnas behov att kunna kontakta den som 
sagt något. Cronholm et al menar att det ska tydligt skall framgå vem som är ansvarig för 
innehållet i meddelandet. Informationen om vem som sagt vad skall lagras som en del i 
handlingsminnet. Kvalitetsidealet skall ses som en uppmaning till att förhindra anonymitet i 
IT-systemet (Ibid.). 

8. Förstå använda begrepp (känd och begriplig vokabulär) 

IT-systemets språk skall motsvara verksamheten och användarnas språk. Det får inte finnas 
någon tvekan om betydelsen av de begrepp som används. IT-systemet skall erbjuda 
förklaringar till alla begrepp som används och en beskrivning av de handlingar som kan 
utföras genom IT-systemet (Ibid.). 

9. Förstå kommunikativ avsikt med olika meddelanden 

Användare behöver förstå vad olika meddelanden (som skärmdokument) betyder 
avsiktsmässigt. Är meddelandet en rapport om något inträffat? Är det en 
handlingsrekommendation? Är det ett en handlingsuppmaning? Är det ett uttryck för ett 
åtagande? Är det ett uttryck för en målsättning? För att kunna använda systemet väl i 
verksamhet som ett kommunikationsinstrument är det nödvändigt att det inte råder någon 
tvekan om liknande typer av kommunikativa avsikter (Ibid.). 

10. Få ett bra stöd för handlande i verksamheten 

Innehållet i skrämdokumentet skall ge goda förutsättningar för att utföra 
verksamhetshandlingar både genom IT-systemet och utanför IT-systemet. Detta innebär att 
den information som visas måste enkelt kunna tolkas samt att de handlingar som erbjuds skall 
vara lättillgängliga. Handlingar ska visualiseras så användaren enkelt förstår om det finns 
relationer och en speciell ordning mellan dem (Ibid.). 


6.9.2 Strategier för utvärdering av IT-system 

För att utvärdera ett IT-system enligt detta synsätt förespråkar Cronholm & Goldkuhl (2003) 
sex olika tillvägagångssätt som kombineras av tre strategier för utvärdering och två strategier 
för vad som utvärderas. 

De tre strategierna för utvärdering av IT-system beskrivs som: 

• Målbaserad utvärdering 

• Målfri utvärdering 

• Kriteriebaserad utvärdering 
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Skillnaden mellan de tre beror på vad som fokuseras i utvärderingen där den målbaserade 
utgår från de mål som finns i organisationen som utvärderingen sker i och målen används för 
att värdera IT-systemet. Med målfri utvärdering menas att inga specifika mål används utan 
den är mer explorativ och inga mål eller kriterier används för värderingen av IT-systemet. Vid 
kriteriebaserad utvärdering ställs ett antal kriterier upp som används som måttstock för IT- 
systemet (Cronholm & Goldkuhl, 2003). 


6.9.3 Målfri utvärdering 

Den målfria utvärderingens syfte är att upptäcka kvaliteter hos objektet som studeras. 
Utvärderaren gör en inventering över de möjliga problemen och får kännedom om objektet 
under utvärderingens gång (Ibid.). 


6.9.4 Målbaserad utvärdering 

Traditionellt sker en målbaserad utvärdering som en kvantitativ process men Cronholm & 
Goldkuhl (2003) menar att den mycket väl kan göras kvalitativ. Den kvantitativa strategins 
syfte är att avgöra om målen är uppfyllda samt vilka mål som är uppfyllda och detta beskrivs 
med kvantitativa termer. Men det finns också sociala och mänskliga mål som också kan 
värderas och dessa uttrycks bäst i kvalitativa termer. Den kvalitativa processen ger alltså 
förutom om och vilka mål som uppfylls, också en möjlighet att visa hur målen uppfylls. 


6.9.5 Kriteriebaserad utvärdering 

Kriteriebaserad utvärdering kan utföras med många olika utgångspunkter, till exempel 
checklistor, principer eller kvalitetsideal. Det typiska vid dessa utvärderingar är att det är IT- 
systemets utseende och interaktionen mellan användare och IT-systemet som är fokus för 
utvärderingen. För att förstå om och hur IT-systemet underlättar de handlingar som utförs i 
organisationen kan mer handlingsorienterade kvalitetsideal användas. Att använda kriterier 
vid utvärdering är att fokusera kvaliteter som, med tanke på det perspektiv som är 
utgångspunkten, är viktiga (Ibid.). 

De två strategierna för vad som ska utvärderas är, enligt Cronholm & Goldkuhl (2003), IT- 
systemet som sådant och IT-systemet i användning. 


6.9.6 IT-systemet som sådant 

Denna strategi tar ingen hänsyn till användarens uppfattning av hur IT-systemet underlättar 
deras arbete. Studieobjektet är IT-systemet och dess avsedda användning genom den 
funktionalitet som kan uppfattas genom att utvärderaren undersöker vad som kan göras i IT- 
systemet (Cronholm & Goldkuhl, 2003). 


6.9.7 IT-systemet i användning 

För att studera IT-system i användning kan flera datakällor användas som till exempel 
intervjuer med användare, observationer av användares interaktion med IT-systemet, IT- 
systemet självt och dokumentation om IT-systemet. Utvärderaren kan välja att kombinera alla 
eller några av dessa datakällor (Ibid.). 
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6.9.8 Målbaserad utvärdering av IT-systemet i användning 

Vid denna form av utvärdering är syftet att se om uppsatta mål har infriats. Utgående från IT- 
systemet, målbeskrivning, kravspecifikation och systembeskrivning studeras interaktionen 
mellan användare och IT-system. En annan möjlig datakälla är intervjuer med användare för 
att fånga deras förståelse, attityder och åsikter gentemot IT-systemet. En beskrivning av 
organisationens mål, IT-systemet samt användarnas förkunskap, IT-mognad, roller och ansvar 
förespråkas. Detta använder utvärderaren för att avgöra om målen har nåtts (Ibid.). 


6.9.9 Kriteriebaserad utvärdering av IT-systemet i användning 

Med detta menas att utvärderingen baseras på fördefinierade kriterier och att objektet som 
studeras är IT-systemet under användning. Perspektivet för utvärderingen är avgörande för 
vilka kriterier som väljs och dessa är därför av stor vikt vid denna typ av utvärdering. I övrigt 
gäller samma som för den målbaserade utvärderingen av IT-systemet i användning (Ibid.). 

Mål- och kriteriebaserad utvärdering är lämpligt att använda när ett tydligt fokuserande 
utvärdering önskas, när det finns få resurser att tillgå eller inga användare tillgängliga. 
Deltagare vid utvärderingen är användare och utvärderingsexpert.(Cronholm & Goldkuhl, 
2003) 

6.9.10 Mitt val av generiska utvärderingsmetoder 

Hur utvärderingen går till beror på vad som utvärderas och vilken hur-strategi som valts, alla 
kombinationer är möjliga vilket ger sex olika typer av utvärdering, Den kombination jag har 
valt är, målbaserad utvärdering som sådan och kriteriebaserad utvärdering med användare. 

Traditionellt sker en målbaserad utvärdering som en kvantitativ process, men Cronholm & 
Goldkuhl (2003) menar att den mycket väl kan göras kvalitativt. Den kvantitativa strategins 
syfte är att avgöra om målen är uppfyllda samt vilka mål som är uppfyllda och detta beskrivs 
med kvantitativa termer. Men det finns också sociala och mänskliga mål som också kan 
värderas och dessa uttrycks bäst i kvalitativa termer. Den kvalitativa processen ger alltså 
förutom om och vilka mål som uppfylls, också en möjlighet att visa hur målen uppfyllts. Hur 
dessa mål uppfyllts inhämtas genom IT-systemets målbeskrivning, organisationens 
målbeskrivning och genom intervjuer och observationer mellan användare och IT-system. 
Eftersom både kvalitativ och kvantitativ ansats kan användas eller kombineras, och det som 
kan mätas med detta tillvägagångssätt är: 

• Om förutbestämda mål uppfyllts eller inte 

• Till vilken grad dessa mål har uppfyllts 

Jag har då valt att se hur målen uppfylls utifrån ISO 9241-11 definition av användbarhet, 
vilket lyder: 1 den utsträckning till vilket en specificerad användare kan använda en produkt 
för att uppnå specifika mål, med ändamålsenlighet, effektvitet och tillfredsställelse. 

Dessa kan då utvärderas enligt: 

Ändamålsenlighet - i vilken utsträckning klarar man uppgiften 
Effektivitet - hur lång tid tar det att klara uppgiften 
Tillfredsställelse - personligt tycke registreras 
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Utvärderingen ska alltså ge kunskap om IT - systemet bidrar till att uppfylla respektive 
målgrupps krav för att bidra till att uppfylla verksamhetens mål. Det ska även vissa IT- 
systemets potentiella positiva och negativa konsekvenser för verksamheten. 

Den kriteriebaserade utvärderingen utgår från fördefinierade kriterier som baseras på IT- 
systemet under användning. Jag kommer att användas de kvalitetsideal som Cronholm et al., 
(2003) har utvecklat för att fastställa om ett IT-system är handlingsbart, i min kriteriebaserade 
utvärdering kommer nedanstående kvalitetsideal att användas: 

1. Enkelt kan förstås vad som kan göras med systemet (tydlig handlingsrepertoar) 

2. Kan ”sägas” det man vill genom systemet (tillgodose kommunikationsbehov) 

3. Enkelt kan ta sig till önskad plats i systemet (lättnavigerbar) 

4. Förstår konsekvenserna av föreslagna och utförda handlingar (handlingstransparant) 

5. Direkt se att det man försökt göra blev gjort (feedback) 

6. Enkelt få hjälp att veta vad som gjorts (tydligt och lättåtkomligt handlingsminne) 

7. Vet vem som sagt vad (”personifiering”) 

8. Förstår använda begrepp (känd och begriplig vokabulär) 

9. Förstår kommunikativ avsikt med olika medelanden 

10. För ett bra stöd för handlande i verksamheten 


Även dessa kriterier kommer att kategoriseras efter: 

• Om kriteriet är uppfyllt eller inte 

• I viken grad kriteriet är uppfylls 

• På vilket sätt kriteriet är uppfyllt 


Den kriteriebaserade utvärderingen skall ge kunskap om IT-systemet motsvarar de valda 
kriterierna. 


6.10 Ekonomiska aspekter 

Att utveckla, framställa och marknadsföra varor och tjänster för med sig kostnader. En del av 
dessa kostnader måste verksamheten ta på sig om det skall bli några varor och tjänster utförda 
och dessutom ge några intäkter (Sandholm, 2001). Mitt syfte är att granska om systemet 
bidrar med oönskade indirekta kostnader som drabbar både verksamheten och deras kunder. 

Genom kartläggning av de processer som IT-system skall stödja får jag fram huvudprocessens 
målgrupp. Det ger mig fakta till att studera hur effektivt den är utformad. Effektivitet kan 
sedan uppskattas i tid och tim - kostnad för respektive målgrupp/målgrupper. Exempel kan 
var om systemet skulle ha automatiserat vissa arbetsuppgifter som inte fungerar, vilket gör att 
personalen måste utföra det som systemet skulle ha bidraget med. Fakturor skrivs inte ut eller 
måste skrivas om (Mayhew & Randolph, 2005). 
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6.10.1 Olika typer av IT-kostnader 

Vad är en IT-kostnad? Rent allmänt så kan man säga att en kostnad är en förbrukning under 
en given tidsperiod. Vilka resurser kan kopplas till IT verksamheten (Fagerström, 2003)? 
Investeringar med kort livslängd betraktas som en utgift som en förbrukad resurs(=kostnad) 
direkt vid anskaffningstillfället. Investeringar med längre livslängd delas utgiften upp i olika 
tidsperioder (år/månad) som finns under investerings livslängd. Den uppdelade utgiften blir 
en periods förbrukning av resursen = kostnad (oftast kallad avskrivningenskostnad) (Ibid.). 

Externa utgifter för service och underhåll av IT-systemet kostnadsförs direkt när utgiften 
uppstår. En tjänst kan inte sparas i lager utan förbrukas direkt. Att utbilda användare för IT- 
systemet med kurser medför kostnader för både kurs- och arbetstidskostnader som läggs ner 
på utbildningen (Ibid.). 

Arbetstid 

De resurser som förbrukas ger en lönekostnad när den egna personalen arbetar med 
investeringar, utbildningen, underhåll och service av de olika delarna i ett företags IT-system. 
Här uppstår en gränsdragningsfråga mellan arbete och utförs vid användning av IT-systemet 
för att lösa olika arbetsuppgifter och arbete som görs för investeringar, underhåll och service 
på systemet. Arbetstid vid användning av IT-system för att lösa olika arbetsuppgifter kan ses 
som en IT - kostnad om man vill mäta och redovisa kostnader. T.ex. om man vill redovisa 
kostnader för alternativa sätt att lösa ett problem med eller utan datorstöd (Ibid.) 

Kringkostnader 

Kringkostnader i samband med en IT - verksamhet förbrukar resurser i from av t ex toner, 
papper till skrivare, lokalkostnader för verksamheten, elektricitet, telefon, etc. (Ibid.). 

Alternativkostnader 

Alternativkostnader är en kostnad som kan uppstå om en annan kostnad väljs framför en 
annan. Exempelvis om kostnader för IT - säkerhetsverksamheten som bedrivs så kan 
alternativkostnaden bli vad det kostar att återställa IT - systemet vid en krasch, kostnader för 
”hackers” som manipulerar informationen eller den kostnaden för en informationsstöld kan 
bli, utan genomförda säkerhetsåtgärder (Ibid.). 

Direkta kostnader och indirekta kostnader 

Direkta kostnader är kostnader som direkt kan hänföras till en IT aktivitet, såsom service och 
underhåll. Medan Indirekta kostnader är sådana kostnader som inte direkt kan hänföras till en 
aktivitet. Exempelvis den extra arbetstid som en arbetstagare måste lägga på att fråga andra 
kollegor hur systemet fungera i ett visst moment. Eller den extra arbetstid det tar att behöva 
vänta på att en resurs (post, system är låst) ska bli ledigt (Ibid.). 

Visa kostnader är mer eller mindre relevanta för den beslutssituation som råder. Kostnader har 
olika grad av rörlighet och vissa kostnader förändras snabbt om ett visst beslut fattas. 
Exempelvis om ett beslut tas om en utbildning för användandet av IT-systemet. Denna 
utbildningskostnad blir till en form av kostnadsbesparing genom att en 
kvalitetsbristkostnadsbesparing görs genom att felhantering undviks (Ibid.). 
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6.10.2 Kostnad av IT-nytta 

Att enbart fokusera på IT - kostnader kan leda till orationella beslut. Det är viktigt att den 
andra sidan av kostnaden vägs in i besluten. Vilka ”nytta” uppnås med den givna 
resursförbrukningen (=kostnad). Att mäta nytta av IT är därför viktigt för att göra goda 
avvägningar vid beslutsfattande kring IT (och andra aktiviteter) i en organisation (Ibid.). 

I en doktorsavhandling om IT - nytta beskriver Fagerström: 

”Individerna anser att utförandet av arbetsuppgifter skall 
underlättas av datorsystemen. Om inte detta sker uppfattas 
systemen som onyttiga. Detta ger en slutsats att verksamhetens 
datorsystem bör förvaltas med avseende på brukarnas 
användningssituationer istället för på systembasis. ”(2003, s. 189) 

Detta gör det svårt att mäta IT - nyttan i from av pengar. Men det är dock möjligt att mäta ett 
antal mjuka variabler och på så vis få fram vilken IT - nytta de anställda upplever vid ett givet 
tillfälle. Den här typen av mätning ger information om IT-systemens bidrag till intern 
effektivitet/individernas utförande av arbete vid ett givet tillfälle och det kan vid första 
mätningen vara svårt att tolka. Om mätningen görs om med samma metod vid senare tillfälle 
ökar dok tolkningsmöjligheterna och materialet kan relateras till både till kostnader och olika 
typer av andra IT - relaterade förhållanden som exempelvis nya programvaror eller utrustning 
(Ibid.). 

Användande av IT-system kan ibland ställas om till en annan besparing. En ny förenklade 
manuell rutin kanske är den billigaste och bästa lösningen. Om digitaliseringen av en rutin 
skall vara kvar bör vara en återkommande fråga när befintlig IT - lösningar granskas. I 
teknikdrivna organisationer kan det ibland vara lätt att fångas av IT-systemets möjligheter 
utan att först ifrågasätta om inte andra lösningar kan vara mer kostnadseffektiva (Ibid.). 

Det går även att mäta de ekonomiska aspektema på användbarhet och det definieras så här 
idag och är internationellt accepterade (SS-EN ISO 4 9241 - 11: 1998) och lyder (Bems 
2004:8): 

”Den grad i vilken användaren i ett givet sammanhang kan bruka en produkt för att uppnå 
specifika mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt.” Den 
svenska översättningen av definitionen ändrades 1999 för att ge en ökad korrekthet till: ”Den 
utsträckning i vilken en specifik användare kan använda en produkt för att uppnå specifika 
mål, med ändamålsenlighet, effektivitet och tillfredsställelse, i ett givet sammanhang.” 


4 / 

(SS-EN ISO innebär att den är antagen som svensk (SS) europeisk (EN) och internationell 
(ISO) standard) 
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Detta är den definition som används i Sverige. Följande begrepp/faktorer i standarden är av 
intresse (Berns 2004:8, s.7): 

• Ändamålsenlighet 

Noggrannhet och fullständighet med vilken användarna uppnår givna mål. 

• Effektivitet 

Resursåtgång i förhållande till den noggrannhet och fullständighet med vilken användaren 
uppnår givna mål. 

• Tillfredsställelse 

Frånvaro av obehag samt positiva attityder vid användning av en produkt. 

Dessa tre ovanstående faktorer kan mätas. De påverkas dock av (Bems 2004:8 s.7): 

• Vem användaren är (person som interagerar med produkten) 

• Användarens situation och fysiska miljö 

• Vad användaren och beställaren vill göra/uppnå 

Alla är faktorer som kan specificeras. Detta innebär att det går att sätta användbarhetsmål och 
att mäta desamma. Definitionen är idag väl använd inom området användartestning och 
utvärdering (Berns 2004:8). 

Följder av interna felkostnader kan vara (Sandholm, 2001, s. 191-192): 

• Fakturan skrivs om, extra dataköming analys måste göras om etc. 

• Ofullkomliga och felaktiga varor får slängas. Exempelvis: dokument, datalistor. 

• Kontrollarbete måste göras om när arbete gjort om. Exempelvis: Granskning av 
omskrivna fakturor, kontroll av den extra datakömingen. 

Externa felkostnader, är kostnader som upptäcks av kunden (Sandholm, 2001, s. 192): 

• Reklamationer mottas och behandlas. Exempelvis: Handläggningen av reklamationer, 
kompensationer till kunder, arbetet görs om, extra material åtgår. 

• Garantiåtagande uppfylls. 

Exempelvis: Återbetalning till kunder, arbetet görs om, nya varor levereras. 

• Priset sänks. Exempelvis: Prisavdrag, generella rabatter. 

• Anseendet försämras. Exempelvis: Förlorad goodwill, negativ publicitet, kunder förloras. 


6.10.3 Kostnad - Nytto - Analys 

IT kan avsevärt öka intäkterna och sänka kostnaderna i en verksamhet, men forskning visar 
dock att endast en tredjedel av IT - investeringarna ger den nytta i verksamheten som är 
möjligt menar Dahlgren m.fl., 2000. IT är en möjliggörare av kvalificerade affärs- och 
verksamhetsutveckling och att satsa på IT är investeringar. Många ser IT som enbart 
kostnader - och ständigt ökande sådana. Men de är ännu viktigare att se vilken nytta som IT- 
kostnaderna skapar och då bör det handla om nettonyttan, det vill säga skillnaden mellan den 
bruttonyttan som skapas och IT - kostnaderna (kostnad för nyttan). De handlar om att utveckla 
de tekniska möjligheterna som finns för att uppnå största möjliga nettonytta i verksamheten. 
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Att fokusera på nyttan innebär att man måste utgå från respektive företags affärsmål. Att hitta 
potentiella nyttor innebär att fokusera på dessa och hur de ska kunna mätas på något sätt. Som 
exempel på mätbara nyttor kan vara att öka antalet kunder i kassan, enklare lära upp ny 
personal, snabbare kunna skriva ut en kassarapport, minskat användare - fel, minskad 
inlärningstid, minskad kundsupport. Nyttor kan sedan uttryckas i enhet av tid och sedan 
omvandlas till kronor, som sedan ger värde på tid enlig Mayhew & Mantei (1994). 

När man beräknar kostnad - nytto - analyser måste man utgå från respektive verksamhets 
affärsmål. Genom att förstå dessa mål kan beräkningar göras hur effektivt gränssnittet stödjer 
dessa. Meyhew & Randolph (2005), Mayhew & Mantei (1994) menar att om ett 
mjukvaruföretag som vill minska sina support- och utbildningskostnader på sitt system bör 
användarekvalitet ses över på gränssnittet. Gränssnittet ska självklart valideras under hela 
utvecklingsprocessen föra att klargöra att målet verkligen uppnås. Ju tidigare i livscykeln 
ändringar görs desto mindre kostnader för att ändra. Om ändringar ändå måste göras efter 
driftsättning kan en enkel kostnadsberäkning vad en ändrings skulle kosta mot att kostnaden 
av en ökad support- och utbildningens kostnad skulle ge. 

Sammanfattningsvis kan sägas att genom ovanstående metoder hoppas jag att få fram vilka 
målgrupper och processer som skapar de effekter som leder till den ökade nyttan som uppstår 
när IT-systemet används i verksamheten. Kopplingen mellan effekter, processer, målgrupper 
och deras användningsmål kommer att skapa underlag för kostnad - nytto - analys i form av 
snabbare processer och effektivare arbetssätt som genererar ett ökat värde både för internt och 
extern. 

Genom att utvärdera IT-systemet med dessa valda metoder där respektive metod har olika 
angreppssätt kommer den insamlade data kunnas ställas mot varandra och kontrolleras. Min 
förhoppning är att det ska bidra till en trovärdigare utvärdering. 

Efter insamlandet med respektive metod kommer jag först att utvärdera varje metod för sig 
och sedan i kombination, med tänkbara problem och fördelar. 
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7. Presentation av IT-system och Återförsäljaren 

Här ges en kort presentation av IT-system, systemleverantören och återförsäljaren för att läsaren 
ska kunna tolka utvärderingen lättare. Informationen är hämtad från systemleverantören och 
återförsäljarens webbsidor och viss omskrivning är gjord för att inte röja företagens identiteter. 


7.1 Systemleverantör X 

Systemleverantör X erbjuder programvarulösningar för återförsäljare inom handel och 
importverksamhet. 

Verksamheten kring Systemleverantör X skapades 1983. Idag är återförsäljarsystemet ett av 
de modernaste och flexiblaste som markanden har att erbjuda. 

7.2 IT-system X 

Programvaran IT-system X är ett professionellt verktyg för återförsäljarens alla avdelningar. 
Programvaran stöder bland annat försäljning och marknadsföring, gränssnitt mot 
ekonomisystem, importörs- och tillverkarsystem. 

IT-system X lämpar sig för användning på en eller flera filialer och klarar att möta behoven 
från en eller hundratals användare. Det begränsar sig inte i funktionaliteten till olika 
varumärken. Eftersom Företag X verkar i många länder över hela världen, finns programvaran 
i olika språkversioner. Ett effektivt språkverktyg möjliggör enkla översättningar till andra 
språk. Fakturor kan till exempel skrivas ut på flera språk, samtidigt som användarens skärm 
fortsätter att visa användarens eget språk. 

IT-system X är baserat på Windows-arbetsstationer (vanliga PC), Microsoft NT 
nätverksoperativsystem och SQL databas. Det optimala systemet för ett företag kan byggas, 
centraliserat eller decentraliserat. Det är möjligt att utnyttja redan befintlig datautrustning. 

Ur nedanstående avdelningar har jag intervjuat 7 respondenter, urvalet har varit 
kundmottagare, 2 st verkmästare, leveransansvarig, reservdelschef, ekonomichef, 
servicemarkandschef samt egen mekaniker. IT-system X erbjuder ett verktyg till: 

• Lageravdelningen som sköter sina kundrelationer systematiskt 

Systemet förenklar säljprocessen och uppföljningen. Man kan förutsäga betalnings- och 
godsflöden, ha kontroll över inkommande varor och följa lagrets storlek och kostnader. 
Lagerdatabasen registrerar alla varors information på alla driftställen. Prisfunktionema hjälper 
till att hålla prislistorna uppdaterade. Återkoppling på försäljningskampanjernas lönsamhet. 

• Inköpsavdelningen som är skicklig att köpa in rätt delar vid rätt tillfälle 

System X varuförsäljningsprogrammet hjälper till att följa med och på förhand beräkna 
varuförsäljningen. Att göra rätt inköp förenklas genom att systemet framställer de mest 
ekonomiska inköpsförslagen. På basis av dessa förslag kan beställningar göras snabbt och 
enkelt. Programmet förser användaren även med verktyg för lagerkontroll och analyser. 

• För ekonomiavdelningen för vilken uppdaterad information är väsentlig 
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Med System X kan lönsamheten övervakas dag för dag, per försäljare, per produktgrupp och 
per försäljningskategori för vilken period som helst. Bokförings specifikationer och 
fakturajoumaler hjälper till att följa med bokföringsförloppet. 

• Till försälj ningsavdelningen med aktivt samband med importören och tillverkaren 

System X är ett effektivt verktyg för att hantera försäljning. Uppdaterade prislistor kommer 
alltid att finnas till hands och ett verktyg för att hantera garantianspråk och för 
beställningsbekräftelser. 

• Till kundmottagningsavdelningen som uppskattar individuell kundservice 

System X kundmottagningsprogram är ett lätthanterligt verktyg för att göra tidsreservationer 
och arbetsorder. Med tidsreservationssystemet kan man på daglig basis hålla ordning på 
arbetsordrar, personalreservationerna och materialreservationerna. 

Standardoperationsprislistor och olika paket förenklar skapandet av arbetsordrar. Möjlighet 
finns att följa varutransaktionernas historik och avdelningens lönsamhet. 
Marknadsföringsprogrammet är ett praktiskt verktyg för att göra erbjudanden och hålla 
kontakt med kunderna. 


7.3 Återförsäljaren 

Återförsäljaren är en av fem anläggningar som ingår i en koncern. Koncernen har som mål att 
vara ledande bil fackhandel inom respektive region. Det skall uppnås genom kvalitet i 
produkter och tjänster och en god fackkunskap hos alla medarbetare, för att ge en hög 
servicegrad och prisvärda produkter. Detta skall bidra till att få nöjda kunder. 

Med sin affärsversion vill man skapa mervärde för sina kunder och en långsiktig lönsamhet 
för sitt företag. Man hade en omsättning runt 600 Mkr 2003 omkring 150 anställda, och 
antalet sålda bilar uppgick till 3 900 st. 

Återförsäljarens målsättning är att sätta kunden i centrum och överträffa dennes förväntningar 
genom högklassiga produkter, engagerad personal och goda kundrelationer skapa en 
entusiasm för sina märken. 
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8. Utvärdering av IT-system 

/ detta kapitel redovisar jag mitt tillvägagångssätt med de fyra valda utvärderingsmetoderna. 
Utvärderingen började medprocessmodellering, mål- och kriteriebaserad utvärdering samt 
kostnad - nytto- analys. Först presenteras en begreppsdefinition, planering och mitt 
tillvägagångssätt och därefter redovisas varje steg i problemsituationen och resultatet 
presenteras. Därefter utvärderar jag problemsituationen, metod och mig själv som utövare. 
Sedan analyserar och diskuterar jag metodernas förmåga att utvärdera. Efter det följer en 
diskussion och analys grundat i den teoriram som jag har presenterat. 


8.1 Begreppsdefinition 

Nytta är ett positivt begrepp. Nytta brukar användas i dagligt tal för att beteckna ett positivt 
värde eller behovstillfredsställelse (Nationalencyklopedin, 2006). 

Effekt är ett neutralt laddat begrepp som pekar på såväl negativa som positiva effekter. 

Effekter tolkas som något mätbart (Ibid.). 

Målgrupper är människor med liknande behov och förväntningar på produkten. Målgrupper 
definieras alltså av det användningsmönster de kan förväntas ha, och inte av datorvana, 
befattning, demografi organisationstillhörighet eller av andra typer av parametrar som kan 
användas för att gruppera människor. Därför gäller det att leta efter olika användningsmönster 
för att tala om vilka målgrupperna är (Ottersten & Balic, 2004). 


8.2 Planering för respektive utvärderingsmetod 

För min studie har jag valt den återförsäljare som geografiskt ligger närmast men även är en 
av de större återförsäljarna. Genom beskrivning och samtal med implementeringsansvarige 
framkom vilka de berörda målgrupperna var. Dessa var ekonomiavdelning, kundmottagning, 
verkstad, lager och säljprocessen. Säljarna arbetar ytterst lite i de utvärderadesystemet men 
leveransavdelningen som tar vid efter dem arbetar säljarna i systemet och ingår därmed. 

Eftersom jag inte har obegränsat med tid är jag tvingad till att inhämta all data på en och 
samma gång. Givetvis kan kompletteringar göras via e-post och telefon. Men denna planering 
har jag gjort för respektive metod. 


78 



Utvärdering av IT-system 


En intervjuram skapades för att fånga data: 

Först fick respondenten bakgrundsinformation om varför intervjun gjordes. 
Nedanstående teman hade jag som utgångspunkt vid de o strukturerade intervjuerna. 

> Respondentens bakgrund (utbildning, dataerfarenhet, hur lång yrkeserfarenhet) 

> Arbetsuppgifter 

> Kundrelationer (synsätt på interna/externa kunder) 

> Företagets vision och mål 


Metod 

Kunskapskälla 

Metod för insamlingsdata 

Processmodellering 

Målgrupper, användare, 
Huvudansvarige 

Intervju & observation 

Målbaserad 

Målgrupper, användare, 
Huvudansvarige 

Kontextuell intervju & 
observation 

Kriteriebaserad 

Kriteriebe skrivningen 
Utvärderingssituation 

Intervju & observation 

Kostnad - nytta - analys 

Målgrupper, användare, 
Huvudansvarige 

Kontextuell intervju & 
observation 


8.2.1 Tillvägagångssätt 

Jag var ute på företaget i två dagar. Dag ett intervjuades servicemarknadschefen för att få en 
övergripande bild av systemanvändandet samt därför att han varit implementeringsansvarig 
för IT-systemet. Därefter intervjuades kundmottagning, verkstad och lager. Dag två, 
intervjuades ekonomiansvarig och leveransansvarig. Sammanlagt intervjuades sju 
respondenter och fördelningen blev en ekonomiansvarig, en kundmottagare av tre, en 
lageransvarig av en, en leveransansvarig av en, samt på verkstaden deltog tre respondenter, 
varav två verkmästare av två och en egen mekaniker av tre. 

Jag valde att använda bandspelare under alla insamlingspassen. Jag ville ha total 
koncentration på respondenten samtidigt som jag då kunde koncentrera mig fullt ut på 
följdfrågor under intervjuerna. Bandspelaren fick även vara på under tiden som jag 
observerade för att fånga eventuella data som jag inte uppmärksammade då koncentrationen 
var riktad på applikationen. Bandspelaren kändes som en stor trygghet och stöd när jag 
agerade som ensam utvärderare. Givetvis frågade jag varje respondent om det var okej att jag 
bandade samtalet. Det var ingen som ifrågasatte eller inte ville vara med. Varje intervju 
började med att respondenten övergripande beskrev sin arbetsuppgift. Därefter visade och 
redogjorde respondenten för hur arbetsuppgifterna utfördes vid datorn. Detta skapade en 
större förståelse samtidigt som jag kunde fråga och ifrågasätta och säkerställa att vi inte 
missuppfattade varandra. Vid ett tillfälle uppkom ett litet problem med att en respondent även 
ville visa hur det fungerade i andra system, men det var inga problem att leda respondenten 
över till rätt system. När alla arbetsmoment var visade så utförde respondenten den 
kriteriebaserade utvärderingen som finns som bilaga (se bilaga 1). Den genomfördes genom 
att jag frågade respondenten om de olika kriterierna. Respondenten svarade eller visade på 
skärmen om kriteriet uppfylldes eller inte. Varje sådan här utvärdering tog 1 Vi - 2 timmar, 
beroende på processtyp. Efter varje avslutad intervju informerades respondenten om att jag 
kanske behövde återkomma per telefon eller e-post om jag missat något eller behövde 
komplettera med någon fråga. 
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8.2.2 Utvärdering enligt Ramverket NIMSAD 

När det gäller tankegången vid utvärderingen av en metod så menar NIMSAD att det ska 
göras före, under och efter (Jayaratna, 1994): 

Problemsituation 

• Före : Att förstå kunden och hans eller hennes önskemål. Välj en metod. 

• Under. Att säkerställa samarbete och förändringar i situationen. 

• Efter: Kontrollera tid, pengar, kvalitet. Gör system et vad det ska? Är problemen lösta? 

Problemlösare 

• Före: Vilka värderingar har vi och vilka kunskaper? 

Metod 

• Före: Hur stöder metoden ”att förstå situationen”? 

• Under: Vilka färdigheter förutsätts? 

En metod ska inte följas slaviskt menar Lind (2001) och Jayaratna (1994). Redan vid första 
angreppssättet måste jag avvika, genom att samla in all information på en gång för de fyra 
metoderna, men när jag analyserar den insamlade data kommer jag att för varje metod byta 
”glasögon” för att få rätt ”synsätt” för metoden som ska spegla metods data, tillvägagångssätt 
och lösning. 

Det kändes naturligt att börja med processmodellering som första metod för att den enligt mig 
ger en grundläggande beskrivning, om ” vad som görs ” och ” vem som gör vad” i IT - 
systemet. Därefter övergår jag till målbaserad utvärdering som är tänkt att utvärdera om 
målgrupperna i IT - systemet kan uppfylla sitt mål. Den kriteriebaserade utvärderingen ska 
hjälpa mig att se om IT - systemet är handlingsbart d.v.s. en utvärdering av gränssnittet 
tillsammans med respektive respondent. Till sist används kostnad - nytto - analys för att 
utvärdera eventuella positiva eller negativa effekter av IT - systemet. 


8.3 Utvärdering med Processmodellering 

Problemsituation före 

Mitt val av denna metod är främst för att klarlägga vilka processer som IT - systemet ska 
stödja. 

Beroende på vem som tillämpar metoden så bör verksamhetskunniga personer vara 
närvarande vid kartläggningen. Men eftersom jag inte kan anordna en workshop, så väljer jag 
att intervjua alla inblandande respondenter i processen. Eftersom jag gör alla interjuver efter 
varandra kan jag kontrollera att arbetsgången är rätt i stora drag. Detta ger även information 
hur samarbetet mellan målgrupperna ser ut, vilket ger en djupare förståelse för 
organisationens kontext och hur det sociala samspelte fungerar mellan målgrupperna. 

Metoden menar att en prioritering ska göras för problematiska och betydelsefulla processer. 
Det är väsentligt, eftersom inget företag kan beskriva och förändra alla sina processer på en 
gång. Jag kommer att använda metoden till att kartlägga vilka processer som IT-systemet X 


80 



Utvärdering av IT-system 


handhar. Detta gör att jag tar ett avsteg ifrån metoden, genom att jag bara följer IT-systemet 
och på så sätt inte kommer att kartlägga vissa processer fullt ut vilket innebär en begränsning 

Jag är fullt medveten om att jag borde se till helheten alltså utanför systemgränserna som 
Jayaratna (1994) påpekar men de andra systemen ingår inte i utvärderingen. Jag tror ändå att 
mitt val kan ge en bra utvärdering av systemets processhantering eftersom en av företagets 
viktiga servicetjänster mot kund ligger i denna process. 


Problemsituation under 

Metoden kräver att man som utövare har kunskap om vad det processorienterade synsättet 
innebär och hur processerna ska ritas upp. 

Genom att jag ritade upp flöden från respektive intervjuinformation (se bilaga 1) kartlägges 
processerna. Jag hittar då både de interna och de externa kunderna. Vidare får jag hjälp av 
metoden att identifiera verksamhetens alla flöden oavsett om de är datoriserade eller inte. 

Kartläggningen av vad som görs och av vem skapar en gemensam bild att sedan utgå ifrån. 
Även om denna bild nu skapas av mig som utvärderar så bör min synbild egentligen kritiskt 
granskas och ifrågasätta. Jag tror att kartläggningen på denna nivå ligger ganska rätt men för 
en djupare analys bör de inblandande delta mer aktivt. Jag resonerade även om min 
kartläggning med min respektive målgrupp för att beskriva arbetsuppgifterna så tydligt som 
möjligt. Givetvis kan ändå missförstånd ske vid kommunikation med respondentema. 

Jag börjar med följande: 

• Jag analyserar intervjuerna med respektive respondenter (se bilagal) 

• Hittar målgrupper 

• Listar kunder 

• Listar resultat 

• Identifierar starthändelser 

• Ritar in områden i processkartan 

• Bestämmer antal processer i processkartan 

• Modellerar processerna 

Jag börjar med att rita upp processkartan för att få fram affärsprocesser och stödprocesser (se 
figur 15). 
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Jag ritar sedan upp huvudprocess (se figur 16) och del av huvudprocess (se figur 17). Till 
dessa huvudprocesser hittar jag stödprocesser lager, ekonomi och servicemarkand. Dessa ritar 
jag inte upp i egna processkartor utan jag beskriver i huvudprocessens flöde hur det stödjer 
den. 

Den process jag har valt till huvudprocess är ”boka service” och det kan tolkas annorlunda om 
man istället väljer att ”köpa bil ” som huvudprocess. Detta beror på att ekonomiansvarig såg 
försäljning av ”bil” som en huvudprocess. Mitt val beror på att försäljning inte ingår i det IT- 
system X som jag ska utvärdera. Jag har valt en halv huvudprocess från försäljning då 
leverans av bil ingår i IT-system. 

Det som var svårast för utvärderingssituationen är att välja ett ”lagom” läge. Det första felet 
jag gjorde var att rita en alltför detaljerad processmodell därför att jag ville kartlägga alla 
moment som målgrupperna gör. Jag insåg att det blev alltför rörigt och gick upp en nivå. Jag 
insåg också att jag inte kunde ta med alla tänkbara starthändelser Det är också svårt att 
utvärdera själv när man inte har någon som kan kommentera/ifrågasätta det man ritar. Jag 
valde att låta ritningen ”vila” ett tag för att se den igen med nya ögon. Nedan redovisas den 
process jag uppfattade som huvudprocessen och som fram togs genom intervjuerna. 
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Återförsäljare X Processmodell Version 2 2005- 05-20 



Nedan följer en beskrivningen av de aktiviteter som görs när starthändelsen startar. 

Process och aktivitetsbeskrivningar 

Process: 1. Kund vill serva bil - tidsbokningen. 

Beskrivning: Kund vill boka tid för service 

Initieras av: Kund vill boka tid för service 

Resulterar i: Servicetid är bokad 

Aktör: Kundmottagare 

Process: 2. Kund vill serva bil - Rådgivningen. 

Beskrivning: Kund vill ha rådgivningen angående service etc. 

Initieras av: Kund ringer eller står vid disken och har behov av råd 

Resulterar i: Servicetid är bokad 

Aktör: Kundmottagare 

Process: 3. Kund vill serva bil - arbetsorder/prisuppgift. 

Beskrivning: Kund får prisuppgift och arbetsorder fylls i 

Initieras av: Kund vill ha prisuppgift 

Resulterar i: Kund vill ha prisuppgift och arbetsorder skrivs 

Aktör: Kundmottagare 
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Process: 

Beskrivning: 


Initieras av: 
Resulterar i: 
Aktör: 


Process: 

Beskrivning: 

Initieras av: 
Resulterar i: 
Aktör: 


Process: 

Beskrivning: 

Initieras av: 
Resulterar i: 
Aktör: 


Process: 

bil. 

Beskrivning: 
Initieras av: 
Resulterar i: 
Aktör: 


Process: 

Beskrivning: 

Initieras av: 
Resulterar i: 
Aktör: 


4. Kund vill serva bil - kolla reservdel finns, arbetsorder skrivs ut. 

Kundmottagaren kontrollerar reservdel finns. Arbetsordern skrivs ut. 
Kundmottagaren lägger arbetsordern i en låda efter detta går kundmottagaren 
till lageransvarige och lämnar beställning på reservdel 

Kund har beställt service 

Kund vill ha prisuppgift och arbetsorder skrivs 

Kundmottagare 


5. Kund vill serva bil - Tar emot beställning. 

Kundmottager ser att reservdel måste beställas hem och går då till 
lageransvarige och lämnar beställning på reservdel 

Reservdel måste beställas till kundens service 
Reservdel tas hem till kunden servicetiden 
Lager 


6. Kund vill serva bil - Fördelning arbetsorder/prisuppgift. 

Verkmästaren fördelar arbetsorderna till rätt kompetens 

Bilar som ska servas 
Bilar som servas 
Verkmästare 


7. Kund vill serva bil - Rådgivningen/kontakt kund angående kundens 


Kund kan kontaktas igen om problem uppstår 

Problem med kundens bil uppstår, kontakt måste tas med kund igen 

Kontakt med kund har gjorts 

Verkmästare 


8. Problemlösning med mekaniker. 

Mekaniker har behov av problemlösningsdiskussion 

Kund vill ha prisuppgift 

Kund vill ha prisuppgift och arbetsorder skrivs 

Verkmästare 
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Process: 9. Renskrivningen och komplettering av arbetsorder till faktura. 

Beskrivning: Verkmästaren renskriver arbetsorder till faktura med tillägg/ändringar 


Initieras av: Kundens bil är färdig servad 

Resulterar i: Fakturan till kund är renskriven 
Aktör: Verkmästare 


Process: 10. Lämnar ut bilen/fakturan/ tar betalt av kunden. 

Beskrivning: Bilen är färdig servad och kundmottagaren tar betalt och lämnar fakturan till 

kunden. Ändrar fakturan om den är fel 


Initieras av: Kundens bil är färdig servad 

Resulterar i: Tar betalt av kund och lämnar ut bilen. 
Aktör: Kundmottagare 


Positiv effektiv för huvudprocess 

Positiva effekter som bidrar till en effektivare huvudprocess. Här väljer jag att även redovisa 
effekten för dem egna mekanikern, eftersom han utför hela huvudprocessen själv. 

Kundmottagare 

• Skapa ett servicepaket. 

• Ta del av historik. 

• Enklare att göra en kreditfaktura. 

Verkmästare 

• Enklare att göra en kreditfaktura. 

Egen mekaniker 

• Enklare att göra en kreditfaktura. 


Negativ effekt för huvudprocessen 

Negativa effekter som hindrar en effektivare huvudprocess. 

Kundmottagare 

• Att inte kunna ge kunden en förstålig prisuppgift, utan att den måste redigeras och 
förklaras, det tar tid. 

• Att arbetsorder måste skrivas ut och läggas i en låda. 

• Att inte kunna uppdatera kunduppgifter på arbetsordema, utan måste behöva göra en ny 
arbetsorder. 

• Att man måste ”gå” till lageransvarige och beställa reservdelar. 

• Att rabatter inte är tydliga. 

• Att ägaruppgifterna inte går att lita på, utan extra förfrågningar måste göras. 


85 



Utvärdering av IT-system 


Verkmästare 

• Att det tar längre tid att fakturera och att verkmästarna måste fakturera. 

• Att rabatter inte är tydliga. 

• Att ägaruppgifterna inte går att lita på, utan extra förfrågningar måste göras. 

Egen mekaniker 

• Att det tar längre tid att fakturera. 

• Tidstämplingen är inte effektiv vid småarbeten. 

• Att rabatter inte är tydliga och försvårar vid fakturering. 

• Lätt att vägledas fel när man lägger till arbetsoperationer på arbetsordern. 


Stödprocesserna 

Stödprocessernas aktiviteter beskrivs endast utifrån hur de stödjer huvudprocessen och vilka 
positiva och negativa effekter de härför en effektivare huvudprocess. 

De stödprocesser som påträffades var lager, ekonomi och servicemarkand. 

Lager 

Jag väljer att redovisa samma beskrivning som i huvudprocessen. 

Process: 5. Kund vill serva bil - Tar emot beställning 

Beskrivning: Kundmottagare ser att reservdel måste beställas hem och går då till 

lageransvarige och lämnar beställning på reservdel 

Initieras av: Reservdel måste beställas till kundens service 

Resulterar i: Reservdel tas hem till kundens servicetid 
Aktör: Lager 
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Servicemarknad 

Stödjer verkstad om mekaniker har glömt stämpla in/ut på fakturan. Förser verkstaden med 
uppföljningsrapporter. 

• Samlar in krav och behov för att utveckla processerna. 

• Stödjer huvudprocessen med support i systemfrågor. 

• Lägger upp nya kunder i systemet 


Ekonomi 

Förser huvudprocessen med ekonomiska rapporter i form av olika typer av rapporter 

• Veckorapporter för lager och leveranser 

• Utfall mot budget. 


Positiv effekt för stödprocesser 

Positiva effekter som bidrar till en effektivare stödprocess. 

Lager 

• Flexiblare sökning gör det enklare att sammanställa en stor artikelfråga. Antingen ska 
informationen visas på skärmen eller skrivas ut. 


Servicemarknad 

• Alla nya rapporter som har tillkommit och att dessa kan förhandsgranskas, även att 
fakturor kan förhandsgranskas innan utskrift. 

• Nu är det mycket enklare att ta ut viktig information förutsatt att alla i systemet sköter sin 
del och stämplar in/ut. 

• Tilläggsmodul i systemet som lätt körs för att se hur långt man kommit med arbetsordern 
(när en kund ringer och frågar). Den visar statusen på en arbetsorder, t.ex. om den är 
färdig och fakturerad eller färdig men inte fakturerad, eller om man väntar på delar. 


Ekonomi 

• Det går mycket enklare och snabbare att hämta information. 

• Det finns en rapport som nu visar försäljningsstatistik och den är väldigt bra och lätt att ta 
fram. 

• Det är positivt med alla förhandsgranskaningar som kan göras på olika listor. 
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Negativa effekter som påverkar stödprocesserna 

Negativa effekter som inte bidrar till att effektivisera stödprocesserna. 

Lager 

• Att det tar lång tid (inte effektivt) att fakturera. 

• Fel verksamhetsspråk försvårar när nya artiklar ska läggas upp. 

• Rabattkoden för respektive artikel får inte plats i sin ruta (fast bara % är i fylld), vilket 
innebär att man inte ser de sista siffrorna. Detta har resulterat i att man fått lägga hela 
rabattkoden i en informationsruta som kan tas fram för respektive artikel. 

Servicemarkand 

• Genvägar till rapporter är konstigt namngivna, vilket innebär att genvägen inte har samma 
namn som rapporten. 

• Verksamhets språket är inte riktigt konsekvent t.ex. benämningar som ”Främmande 
arbete” och ”underleverantör” gör att det blir diskussioner om vad som är vad. 

Ekonomi 

• Det finns ingen bra rapport som fångar upp försäljningen från servicemarknaden 
framtagen ännu, men det ligger under prioriterade ärenden. 

• Det man saknar är en direktkoppling mellan systemen (IT-system X och 
bokföringssystemet) nu har inte batchkörningen fungerat (ska köras varje natt, är det 
tänkt) utan man har fått plocka siffror manuellt mellan systemen. 

• Vid selektering av information till en rapport kan vissa urval göras, men dessa 
inställningar är inte enkla att göra. 

Sammanfattningsvis så är huvudprocessen inte effektiv. Det är inte bara för att IT-systemet 
inte stödjer ett processorienterat arbetssätt eftersom IT-systemet är mer specialiserat på 
funktioner. Utan det är att kundmottagningens funktioner är ineffektiva med bl.a. arbetsorder 
som inte kan lagras i systemet, felaktig data på ägare och bil, rabatter inte tydligt angivna, 
uppdateringar från bilregistret som inte fungerar, prisuppgifter som inte stämmer, etc. Även 
verkstad är ineffektiv, där verkmästarna har fått ta över kundmottagarnas arbetsuppgift med 
fakturering tack vare att IT-systemet inte fungerar som tänkt med tidstämplingen. Det är 
allvarligt att dessa två viktiga målgrupper som kundmottagning och verkstad som är ansiktet 
utåt och verkligen ska vara de som skapar och vårdar kundrelationer har fått sämre funktioner 
att arbeta med. Medan stödprocesserna har minst problem och är effektivast har även 
servicemarknad blivit en mycket effektiv process som skapar effekt för verksamheten. 
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Del av huvudprocessen - försäljningen 

Affärsprocess bilförsäljning kan också ses som en huvudprocess, men eftersom säljprocessen 
ligger i ett annat system så har jag bara tittat på leveransprocessen. 


KUND 

VILL 

KÖPA 

BIL 



KUND 

HAR 

KÖPT BIL 


Nedan följer en beskrivning av de aktiviteter som görs när starthändelsen inträffar. 

Process och aktivitetsbeskrivningar 

Process: 1. Kund vill köpa bil - Dokument från säljaren. 

Beskrivning: Säljaren har förberett säljdokument som försäljningschef har godkänt, detta 

dokument kommer nu via ett annat system in i system X, och ska 
kompletteras med uppgifter 

Initieras av: Säljaren vidarebefordrar säljdokument 

Resulterar i: Dokumentet kontrolleras och kompletteras med det som fattas 
Aktör: Leveransansvarig 


Process: 2. Kund vill köpa bil - Finansiering färdigställs. 

Beskrivning: Leveransansvarig kontrollerar och förbereder för finansiering 

Initieras av: Kund vill finansiera bilköp 

Resulterar i: Finansiering har förberetts för kund 
Aktör: Lageransvarig 
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Process: 

Beskrivning: 

Initieras av: 
Resulterar i: 
Aktör: 

Process: 

Beskrivning: 

Initieras av: 
Resulterar i: 
Aktör: 


Process: 

Beskrivning: 

Initieras av: 
Resulterar i: 
Aktör: 


Process: 

Beskrivning: 


Initieras av: 
Resulterar i: 
Aktör: 


Process: 

Beskrivning: 


Initieras av: 
Resulterar i: 
Aktör: 


3. Kund vill köpa bil - Kunden köper begagnad. 

Lageransvarig förbereder begagnad bil 

Lageransvarige förbereder begagnad bil 
Begagnad bil har förberetts 
Leveransansvarig 

4. Kund vill köpa bil - Kunden köper ny bil. 

Lageransvarig beställer ny bil 

Lageransvarig beställer bil från fabriken (samordningen) 

Bil har beställts 

Leveransansvarig 


5. Kund vill köpa bil - Bilen ska registreras. 

Bil måste registreras 

Leveransansvarig registrerar bilen 
Bilen är registrerad på köparen 
Leveransansvarig 


6. Kund vill köpa bil - Bil ska färdigställas. 

Bil ska färdigställas ute på verkstaden innan kunden hämtar bilen, t.ex. ska 
besiktning av dragkrok utföras etc. 

Bil ska göras i ordningen åt kunden 
Bil har gjorts klar för kunden 
Verkstad 


7. Kund vill köpa bil - Bilen ska överlämnas till kunden. 

Säljaren överlämnar bilen till köparen och alla andra papper som 
leveransansvarig har gjort i ordningen för bilköpet 

Bilen ska överlämnas till kunden 
Bil har överlämnats till kunden 
Säljaren 
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Positiva effekter för del av huvudprocessen i säljprocessen 

Positiva effekter som bidrar till en effektivare säljprocess. 

Leveransansvarig 

• Samlingsfaktura, nu kan en order innehålla flera bilar. 

• Faktura kan enkelt delas upp på flera intressenter. 

• Enkelt att göra en kreditfaktura. 

• Enklare och bättre sökbegrepp. 


Negativa effekter för del av huvudprocessen i säljprocessen. 

Effekter som påverkar delprocessen negativt 

Leveransansvarig 

• Det upplevs som om man fyller i mer än som gjordes innan dokument hanteringen blev 
datoriserad. Det går inte att välja att viss information ska ligga som standard. 

• Dokumenthanteringen mellan systemen fungerar inte utan information tappas vid 
överföring, vilket medför merarbete. 

• P.g.a. litet teckensnitt på applikationen är det svårt att läsa och tyda siffror efter en hel dag 
vi datorn. 

• Vid uppdateringar i systemet försvinner namnetiketter på applikationen. 

Sammanfattningsvis så har arbetsuppgiften fakturering för leveransansvarig effektiviserats 
genom att underlaget från respektive säljare ligger i systemet. Men eftersom systemet tappar 
information mellan säljare och leveransansvarig. Innebär det att leveransansvarig måste gå 
igenom och kontrollera dokumentet. Därmed försvinner den positiva effektiviteten. 

Kreditfakturering har också gjorts effektivare och kräver inte längre manuell hantering. 
Positivt är även att en order kan innehålla flera bilar och kan delas upp på flera intressenter. 


Problemsituation efter 

Min tolkning är att IT-system X skall stödja dessa processer. Det jag ser som huvudprocessen 
är delprocesserna kundmottagning (figur 15, (1)) och verkstad (figur 15, (2)). Nästa viktiga 
process är bilförsäljning, därav min ritning ovan. Bilförsäljning är en viktig del i 
kundrelationen p.g.a. av att man vill knyta nära och hållbara relationer till kunden. Målet är att 
få ett hållbart kretslopp med försäljning och service. Detta för att bilförsäljningen (figur 
15,(3)) ingår till stor del i ett annat delsystem och det är endast delprocessen leverans (figur 
15,(4)) som ingår i IT-systemet X. Delprocesserna ekonomi, lager och servicemarknad är s.k. 
stödprocesser till kundmottagning och verkstad. 

Processmodellering ser jag som en metod som utgår från användarnas behov och kräver deras 
närvaro. Den klarlägger vad som verkligen görs i ”idagprocessen”, vilket innebär att det är de 
som arbetar i respektive process som måste delge sin syn för att uppnå den verkliga 
”situationen”. Efter det tas en gemensam ”imorgonprocess” fram, vilket skapar det ”önskade 
tillståndet”. Jag följer inte steget att skapa imorgonprocessen eftersom jag bara vill utvärdera 
idagprocessen. 
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När allt nu är färdigdokumenterat upplever jag att dokumentationen ger en bra överblick över 
”vem som gör vad” och ”vad som görs”. Oavsett att jag nu bara använder en del av 
verktygen som finns till förfogande för modelleringen så upplever jag att dem är relativt enkla 
att använda. Metoden visar mig verkligen hur arbetet utförs ”idag”. Denna bild visar att IT- 
systemet inte är processbaserat utan funktionsorienterat. Det visar sig också att respektive 
målgrupp är starkt fokuserad på sin ”arbetsuppgift” och man är inte helt medveten om att 
processen gör onödiga moment. Det visar sig även att stödprocesserna är de starkaste medan 
huvudprocesserna är de som har mest problem för att serva de externa kunderna. Nu kan det 
ifrågasättas när systemet är funktionsorienterat och metoden processbaserad men jag anser 
ändå att det framkommer stora brister i handhavande mot slutkund som borde ifrågasättas. 


Översikt över egna lösningar under metodens såns 

Jag hade ingen workshop med målgrupperna utan kartlade istället processen efter intervjuer 
(se bilagal). Jag kartlade endast idagprocessen och valde processen(kundmottagning, 
verkstad) till huvudprocessen. Samtidigt tog jag beslutet att välja försäljning till en halv 
huvudprocess p.g.a. att säljarens arbetar i ett annat system och det ingår inte i utvärderingen. 
Normalt brukar det bara finnas en huvudprocess men jag valt två huvudprocesser och 
modellerade en halv försäljningsprocess eftersom leveransansvariges arbetsuppgifter utförs i 
utvärderingssystemet. Det som kan tolkas som negativt, vilket Jayaratna påpekar, är att min 
gränslinje dras runt IT-system X som ska utvärderas. Jag borde ha utgått från helheten. 

Metoden ger en klar bild över den situationen som råder i såväl huvudprocesserna som 
respektive stödprocesser. Och jag upplever att modellen har lyft fram och klarlagt både 
styrkor och svagheter i processerna. 


8.3.1 Analys och diskussion utifrån Ramverket 

Jag har valt att analysera och diskutera problemsituationen före, under och efter 
tillsammans. 

Problemsituationen 

Metoden kartlägger hela verksamheten men utövaren rekommenderas att avgränsa 
problemområden för det går inte att förändra allt på en gång. Metoden rekommenderar och tar 
fram ”nuläget för processen” och sedan det ”önskade tillståndet”. Min tanke är att bara 
kartlägga IT-systemets processer, vilket kan ha gjort att viktiga aspekter missats enligt 
Jayaratna. T.ex. så utreder jag inte orsaken till den tappade informationen mellan säljare och 
leveransansvarig p.g.a. min dragna gränslinje som gäller endast för detta IT-system. Nu beror 
den dragna gränslinjen på att utvärderingen endast gäller IT-system X. Men jag ser att 
metoden har avslöjat för mig att problemet kan ligga på säljarens sida. I detta läge tycker jag 
att metoden verkligen ser och uppmärksammar mig som utövare på nya processer som skulle 
behövas granskas. 

Grundtanken är att det är de personer som är aktiva i processen som bör kartlägga den, inte en 
utomstående som jag. Jag valde att istället utgå från respektive intervjuunderlag för att göra 
kartläggningen. Detta tycker jag fungerade bra för att få fram en bild över hur processerna 
fungerade men kartläggningen blir då mer generell. Men även det samförstånd mellan 
personalen som byggs upp under en workshop missar jag som en ensam utövare. Detta behövs 
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om organisationen ska införa ett processynsätt som medför ett nytt arbetssätt. Genom allas 
medverkan förbereds ett förändringsarbete lättare. Nu ser respondenterna sig själva som 
enskilda kuggar, och inte som en kugge i en kedja med aktiviteter som bidrar till nöjda 
kunder. 

Jag tycker att metoden har bra verktyg för att utföra en bra prognos över ”problem 
situationen” som Jayaratna påpekar är viktigt. Om kartläggningen görs tillsammans med 
användarna så hindrar det att problemlösarens sinnen stängs av. 


Metodutövaren 

Min eget synsätt av processmodellering överensstämmer med vad Sandberg (2001) säger om 
att det verkligen är de som arbetar i processen som ska kartlägga den, även om jag nu gjorde 
det själv med hjälp av respondentemas information. Metoden kräver kunskap om hur 
modelleringen ska göras och ett processynsätt. Men det behövs ingen kunskap om området 
som processen ska modelleras i. Det är helt upp till utövaren hur deltagandet från 
verksamheten ska se ut. Min tolkning är att det styrs av verksamhetens ledningsfilosofi. Det är 
även upp till utövarens etik och moral om problem ska upptäckas eller inte. Exempelvis så 
påpekar jag att kundmottagaren inte själv beställer servicedelar utan går till lageransvarig. Nu 
hade jag tidigare även fått bekräftelse från ekonomiansvarig (se intervju bilaga 1) att 
organisationen är starkt funktionell. Detta medför att målgrupperna har sitt expertkunnande 
och därmed gränser för vad som "är deras område". 


Metoden 

Det tar ett tag att modellera upp processerna vilket kan ses som en nackdel men jag tror det 
också är en vanesak. Det behövs också kunskaper om vad processmodellering innebär. Det 
gäller att hitta den rätta blicken och förståelsen för processer för att modelleringen ska bli rätt. 

Metoden drar gränslinjer och ger rekommendationer till utövaren. Metoden menar att allt inte 
kan lösas på en gång. Både ”nuläget” och ”imorgonprocessen” kan ritas upp eller endera. Det 
är sedan meningen att den eventuella konceptuella modellen ska utgå från imorgonprocessen. 
Metodens ritverktyg är enkla att använda men det krävs träning innan och en viss tid att lära. 
Metoden fångar i första hand de funktionella kraven för det kommande systemet. Metoden ser 
inte till någon social kontext i organisationen eller tar hänsyn till maktstrukturer och 
kompetenser utan fokuserar helt på vad kundens behov är. Men den ger en bra 
kundfokusering på intern/extern kund. Metoden har ett rationellt angreppssätt som fokuserar 
på vad som görs och vem som gör vad, oavsett om det som görs är IT - baserat eller inte. 

En stor fördel som jag upptäckt var att även om verksamheten var funktionsorienterad, så 
utvärderades målgruppernas funktioner och arbetssätt på ett bra sätt. Jag ser 
processmodellering som ett effektivt sätt att utvärdera på. Eftersom metoden är inriktad på 
”vem som gör vad” så utvärderas inte gränssnittet och, därför behöver metoden kompletteras 
med en sådan metod. 

Metoden är även bra för att på ett enkelt sätt se vilka funktioner som behövs för ett 
standardsystem. Att införa ett processbaserat arbets- och synsätt kräver ledningens 
engagemang enligt mitt synsätt. Det skall enligt mig göras innan och inte med hjälp av ett IT- 
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system. Det bör även beaktas att organisationen är funktionsorienterad med specialister där 
reviren mellan funktioner är stor. 

Sammanfattningsvis tycker jag att metoden stödjer de tre stegen förstå situationen, förbereda 
en diagnos, och definiera problem för problemlösningsprocessen som Jayaratna menar att en 
metod bör göra. Jayaratna menar vidare att en de största svagheterna bland många metoder är 
att de inte är intresserade av vad som egentligen händer i organisationen. Jag är beredd att 
hålla med Jayaratna till viss del, men för denna metod hävdar jag dock att det beror helt på 
utövarens och verksamhetens filosofi. Antingen görs modelleringen tillsammans med berörda 
användare och delaktighet visas genom ledningens engagemang, eller också görs 
modelleringen tvärtom. 


8.3.2 Teoribaserad analys och diskussion utifrån organisationens 
perspektiv 

Här genomförs en analys och diskussion med utgångspunkt i teorikapitlet informationssystem 
och användbarhet. 

Jayaratna (1994) menar att ett informationssystem ska ses i förhållandet till sin verksamhet. 
Informationssystem existerar inte för sin egen del utan för att stödja en verksamhet. Jayaratna 
menar vidare att i dagens konkurrens mellan olika verksamheter är det viktigt att 
informationssystemet utformas på rätt sätt. Därför tycker jag att processynsättet är en bra 
metod att verkligen synliggöra vad som verkligen görs och av vem, dessutom är det 
kundfokusering i första hand. Observera att detta förutsätter att de som verkligen arbetar i 
processen och kan alla aktiver är med vid kartläggningen. 

Jayaratna menar att en svaghet som många metoder har är att de egentligen inte bryr sig om 
vad som händer i organisationen, men det upplever jag att det gör processynsättet med rätt 
perspektiv. Men förutsatt att filosofin utgår från ledningen och att ett processynsätt införs i 
organisationen innan systemet. Detta stämmer då bra överens med vad Jayaratna menar att en 
stor vikt bör läggas på att förstå organisationen och dess syfte, för att designa ett bra system. 
Systemet designas sedan efter aktiviteterna och deras syften. Även Gulliksen & Göransson 
menar att man måste på absolut bästa sätt samla in den kunskapen om användarna, och det 
bästa sättet är genom att mer eller mindre leva i deras arbetsmiljö. Vi måste alltså ut till 
användarnas arbetsplats för att lyckas fånga saker som inte går att fånga på annat sätt än med 
fysisk närvaro. Processmodelleringen med användaremedverkan ger en bra grund för att få 
fram ”vad som görs” och ”vem som gör vad”. Att sedan modellera idagprocess respektive 
imorgonprocess ger användarna ett bra sätt att påverka till en effektiv process. Vissa kan 
påpeka att det bara kommer att ställa till problem för användarna är bara oense och vill ha sin 
egen personliga vilja igen. Visst kan det vara så, men då gäller det att ha en bra ledare som 
kan lyfta blicken och lotsa användarna till en gemensam lösning, som är effektiv för både 
intem och extern kund. 

Jag upplever att metoden verkligen visade på de svagheter och styrkor som finns i systemet. 
Metod visade klart på att huvudprocessen är den process som fungerar sämst medan många 
stödprocesser fungerar mycket bättre. Nu är systemet ett standardsystem som är mer 
funktionsinriktat och implementerat ute hos c:a sjuttio återförsäljare. Men även utifrån detta 
perspektiv så är de målgrupper som främst möter kunder mest drabbade av att systemet inte är 
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effektivt, medan vissa delprocesser som exempelvis servicemarknad är väldigt effektiv och 
kan stödja huvudprocessen bra. Men både Jayaratna, (1994)och Gulliksen & Göransson, 
(2002) påpekar vikten av att förstå användarna för att skapa effektivare informationssystem 
och då är frågan om inte en leverantör av ett branschsystem bör ha bättre kännedom om 
respektive målgruppers behov. Det har de säkert, men de ser inte återförsäljarens verksamhet i 
processer utan i egna avskilda funktioner, och det gör även återförsäljarna. Men även om de 
har det synsättet så finns de viktiga funktionerna, men de är inte effektiva. 

Även om återförsäljarna skulle vilja ändra sitt arbetssätt till ett mer processinriktat sådant så 
kan det inte införas utan vidare, utan det kräver en noggrann planering för att detta påverkar 
organisationens kultur, status, arbetsfördelning, och sociala kontext etc. Jayaratna (1994) 
menar att många företag inte tar någon som helst hänsyn till en organisationsförändring. Det 
finns alltså kritiska faktorer som påverkar om systemet ska bli en framgång eller inte. Det 
behövs alltså kännedom innan införandet och en planering hur omläggningen ska göras. Det 
kan handla om hela organisationens arbetssätt och sådant ändras inte under ett par veckor. 

Jag menar att med processmodellering som utvärderingsperspektiv så måste även utövaren 
granskas för sitt syfte. Min uppfattning av metoden är att den är bra men att det är utövaren 
som bestämmer syfte och perspektiv. Det som är en nackdel med metoden är att den inte 
möter användarnas icke-funktionella krav. Därför kan en perfekt modellerad process i ett IT- 
system som utgår från användarnas behov bli helt ineffektivt p.g.a. av att gränssnitten inte har 
en bra användbarhet som bidrar till en effektiv arbetssätt. Detta har lämnats helt åt godtyckligt 
tyckande. 

Utvärderingsmetoden processmodellering påvisade att de målgrupper som var mest 
tillfredsställda med det nya IT-systemet var målgrupper som definierades som stödprocesser, 
vilket innebär att det enligt processynsättet är huvudprocessen som har flest brister. Detta ser 
jag som en stor nackdel för även om återförsäljarna inte arbetar processorienterat så påverkar 
det deras kapacitet att arbeta effektivt. Nu har de blivit lovade att många av problem ska 
åtgärdas vid nästa uppdatering men det får inte innebära konsekvenser, som t.ex. att 
gränssnittet tappar sin ledtext för leveransansvariga. Det påminner dock om liknade problem 
som Ljungberg & Larsson (2001) tar upp att varje programversion är full av buggar som 
måste elimineras i uppdateringen. De nya versionerna innehåller dock nya möjligheter, vilket 
också innebär att ett antal nya buggar förs in. 

o 

Återförsäljaren har inlett en diskussion om att införa ett mer processorienterat arbetssätt, men 
målgrupperna är starkt funktionellt inriktade. Men ur konkurrenssynpunkt är det viktigt att se 
vilka olika möjligheter som finns och som Ljungberg & Larsson (2001) beskriver är en 
verksamhetsprocess det som utgör att system kan förverkliga affärsidén. Det är processerna 
som skapar värde för kunderna. Processerna avgör vad som produceras men också hur. I en tid 
när differentieringen svårligen uppnås på basis av eventuell fysisk produkt, är processerna 
ofta det enda som skiljer det ena företaget från de andra. Därför sågs de nya IT-systemet som 
en naturlig del i strategi att effektivisera verksamheten. Viktiga moment har datoriserats så 
som sälj dokumentet mellan säljare och leveransansvarig. En annan effektiv funktion har 
genererats för att snabbt kunna ge kunden besked om hur långt man hunnit på kundens bil. 
Detta gör att man nu slipper springa runt och fråga mekaniker eller verkmästare. Vidare har 
hantering av kreditfakturor effektiviserats som i det gamla systemet var väldigt omständligt 
och i vissa fall fick lösas manuellt med vanlig skrivmaskin. Tidsstämpling har introducerats 
vilket innebär att varje mekaniker som arbetar på en order måste stämpla in och ut på ordern. 
Detta bidrar till en effektiv rapportering av mekaniker per faktura. 
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8.4 Utvärdering med Målbaserad utvärdering 

Problemsituation före 

Metoden tar hänsyn till både kvalitativa och kvantitativa mål, men målen ska vara härledda ur 
organisationen kontext. Skälet till mitt val av den målbaserade metoden var att se om 
respektive målgrupps mål var uppfyllda utifrån från ISO 9241-11 (1998) definition av 
användbarhet. Dessa mål granskas utifrån ändamålsenlighet, effektivitet och tillfredsställelse. 
Jag kan inte göra några mätningar, utan utgår från respektive respondents upplevelser och 
egna tolkningar. När respondenterna uppger att det inte har blivit enklare/snabbare eller tar 
längre tid, så refererar de till det gamla systemet som de hade innan. Det var ett gammalt 
textbaserat system som varit i drift i tjugo år. 

Jag började analysera intervjuerna och mina egna tolkningar från processkartläggningen (se 
sammanställning av intervjuerna bilaga 1) men även vad jag observerat under den 
kontextuella intervjun när respondenterna utförde sina arbetsuppgifter. Därefter planerade jag 
för hur svaren skulle dokumenteras och kom fram till att en tabellform var det bästa. 

Jag valde att bedöma hur ändamålsenlighet, effektivitet och tillfredsställelse var uppfyllda 
enligt nedanstående bedömning: 

• Om förutbestämda mål uppfyllts eller inte 

• I vilken grad dessa mål uppfyllts 
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Problemsituation under 

Sedan granskade jag varje målgrupp utifrån respektive mål för (ISO 9241-11, 1998): 

• Ändamålsenlighet 

Noggrannhet och fullständighet med vilken användarna uppnår givna mål 

• Effektivitet 

Resursåtgång i förhållande till den noggrannhet och fullständighet med vilken användaren 
uppnår givna mål 

• Tillfredsställelse 

Frånvaro av obehag samt positiva attityder vid användning av en produkt 


Det första målet ändamålsenlighet var det svåraste att utvärdera eftersom det innehåller både 
noggrannhet och fullständighet. Alla respondenter klarade av att utföra sina arbetsuppgifter 
men vissa målgrupper var tvungen att vara extra vaksamma, därför att information inte var 
korrekt. Jag gjorde den bedömningen att alla klarade av att utföra sina arbetsuppgifter. I målet 
effektivitet lades då till den bedömningen att informationen inte var korrekt. 

Effektivitet bedömdes utifrån varje respondents uttalande om hur de upplevde att det var att 
utföra arbetsuppgiften i det nya systemet. Även målet tillfredsställelse gjordes efter denna 
bedömning. 

Nedan visar jag hur jag valde att bedöma målet: 

Uppfyllt = Jag anser att målet är uppfyllt när respondenten klarar uppgiften. 

Delvis uppfyllt = Jag anser att målet är delvis uppfyllt om 50/50 är uppfyllt/ej uppfyllt och de 
ej uppfyllda är av sådan karaktär att det direkt påverkar de nödvändiga arbetsuppgifterna. 

Ej uppfyllt = Jag anser att det givna målet ej är uppfyllt, och är en självklarhet för att utföra 
arbetsuppgiften. 
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Problemlösningsprocessen efter 


(Hur jag har bedömt varje mål finns i bilaga 2). 

Tabell 3, Resultat målbaserad utvärdering _ 



Service¬ 

marknad 

Ekonomi 

Lager¬ 

ansvarig 

Kund¬ 

mottag¬ 

ning 

Leverans¬ 

ansvarig 

Egen 

mekaniker 

Verkstad 

Ändamålsenlighet 

- i vilken 
uträckning klarar 
respondenten 
uppgiften 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Effektivitet - hur 

lång tid tar det att 
klara uppgiften 

Uppfyllt 

Ej 

Uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

Tillfredsställelse 

- Här är det 
respondentens 
personliga tycke 
som registreras 

Uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

Delvis 

uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 


Allt som allt så är servicemarknad den målgrupp som IT - systemet stödjer fyllt ut medan 
verkstad, egen mekaniker och ekonomi har det sämsta IT - stödet. 

Översikt över egna lösningar under metodens gång 

Jag valde att dokumentera svaren i tabellform (bilaga 2). Men för att skapa en bättre översikt 
så sammanställde jag målen i en matris. Jag utgick från ett eget sätt att dokumentera på 
eftersom metoden inte gav några direkta direktiv för dokumentation förutom mållista och 
målgrafer, som jag inte ville använda. Metoden gav inte heller några råd eller direktiv för hur 
man skulle avgöra om målen var uppfyllda eller inte. 


8.4.1 Analys och diskussion utifrån Ramverket 

Jag har valt att analysera och diskutera problemsituationen före, under och efter 
tillsammans. 

Problemsituationen 

Metoden fylls med mål som utövaren eller kunden har definierat utifrån det som ska 
utvärderas i verksamheten. Dessa mål granskas om de är uppfyllda eller inte. Det är alltså helt 
upp till utövaren att bedöma om målen räcker för att kartlägga problemsituationen. Metoden 
ger inget stöd för utvärderingssituationen utan allt ansvar läggs på utövaren. 

Det tog ett tag att tänka igenom hur jag bäst skulle utvärdera de mål som jag hade satt upp. 

Att utvärdera målen Ändamålsenligt, Effektivitet och tillfredssällelse mål är konstruerade så 
de ska kunna mätas. Jag hade inga möjligheter att genomföra några mätningar i form av 
tidtagningar utan gick istället på de underlagen från intervjuerna och observation, men även 
från processmodelleringen. 
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Målet Ändamålsenlighet valde jag att tolka på det sättet att alla klarade av uppgiften oavsett 
att vissa saker inte stämde och kunde bli fel. Att det kunde bli fel och att informationen var fel 
noterades i stället i för målet Effektivitet. Bedömningen var hur lång tid det tog att klara 
uppgiften. Jag mätte inte, utan det var respektive respondent egen tolkning som låg till grund. 

Målet Tillfredsställelse är användarens personliga tycke, vilket rekommenderads att fångas 
med frågeformulär. Min bedömning blev re sponden temas eget uttalande i intervjuerna, vilket 
jag ser som lika trovärdigt som att be dem fylla i en enkät i just detta sammanhang. 

Jag valde själv att använda kriterierna Uppfyllt, Ej uppfyllt respektive Delvis uppfyllt för 
utvärderingen av målen. 

Resultatet jag fick visar att målet Ändamålsenlighet är uppfyllt hos alla målgrupper. Målet 
Effektivitet är endast uppfyllt hos servicemarknad och delvis uppfyllt hos målgrupperna lager 
och kundmottagning. Medan det inte är Ej uppfyllt hos leverans, egen mekaniker, ekonomi 
och verkstad. Tillfredsställelse var endast servicemarknad som upplevde resten av 
målgrupperna hade inte den upplevelsen. Sammanfattningsvis så var det bara servicemarkand 
som hade alla målen uppfyllda. 

Faserna för problemformuleringen som Jayaratna menar att en metod bör följa, upplever jag 
att metoden endast gör bra i ”situation av intresse”. Att förbereda en diagnos, en plan för 
prognos och definiera problem upplever jag att mina egna lösningar gjorde bättre än 
metodens. En mållista som bilda ska blida en målgraf, passar inte för min kombination, då 
alla mål är lika viktiga. 


Metodologiutövaren 

Målbaserad utvärdering utgår helt ifrån utövarens filosofi det är helt upp till utövaren vilka 
mål som ska utvärderas och hur de ska utvärderas. 

Att välja kriterierna för ISO 9242-11(1998) som mål att utvärdera gör jag därför att jag vill se 
om IT-system uppfyller dessa mål. Eftersom är användbarhet är ett så mångfasetterat begrepp 
och det finns olika tolkningar att utgå ifrån kändes dessa mål bra att ställa mot den 
kriteriebaserade utvärderingen. 

Metodologin 

Metoden utgår helt från den utövare som ska använda metoden. Metoden kan användas för 
både kvalitativa och kvantitativa mål. Metoden drar inga gränslinjer utan utgår från hela 
organisationens mål. Metoden ska granska de målen som utövaren eller klienten har ställt upp. 
Metoden ger inget stöd för hur målen ska utformas eller dylikt. 

Metoden säkerställer inte samarbete eller förändringar utan kontrollerar bara uppsatta mål 
utifrån utövaren. Metoden kändes först svår att förstå därför att den inte fanns direktiv att 
följa. Målen som skulle bedömas skulle tas fram av utövaren. Det är upp till metodutövaren 
att bestämma krav och nivåer som ska bedömas. Det förutsätts att utövaren förstår 
verksamheten och dess kunder. Metoden löser inga problem eller förbereder någon 
förändringsprocess den bara redovisar uppsatta mål från utövaren. 

Metoden har inga regler om hur dokumentation ska göras förutom att redovisa målen i en 
målgraf. Jag valde att gör avsteg från det därför att jag upplever att det blir mer realistiskt och 
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överskådligare att redovisa om målen var uppfyllda eller inte. Metoden ger ingen inblick över 
hur arbetet är organiserat. Kan metoden exempelvis lösa en ineffektiv fakturahantering? Ja, vi 
uppmärksammar att något är fel men, inte vad. Oavsett hur väl vi definierar våra mål, för att 
varje målgrupp ska få ett effektivt gränssnitt, så kan det vara så att vi i alla fall inte uppnår de 
förväntade målet. Därför att det inte uppmärksammas vad som orsakar den ineffektiva 
fakturahanteringen. 

Metoden tillsammans med ISO 9242-11 (1998) tar ingen hänsyn till hur arbetet är organiserat. 
Vilket gör att den inte upptäcker en ineffektiv process för exempelvis fakturering. Fokus blev 
helt på utförandet av arbetsuppgiften men ingen helhet togs fram. Den fångade inte heller 
funktioner som inte används eller andra problem som härrör till människans kognitiva 
processer. 


8.4.2 Teoribaserad analys och diskussion utifrån IT-systemets 
information 

Här görs en analys och diskussion utifrån teorikapitlet informationssystem och användbarhet. 

Målet med den målbaserade utvärderingen var att se hur IT-systemet stödjer respektive 
målgrupp i att utföra sina arbetsuppgifter. Jayaratna menar att ett systems huvudsakliga 
uppgifter är att skaffa information för att stödja användarnas beslutstagande oavsett nivå i 
organisationen. Denna rollfunktion måste vara effektivt organiserad för att stödja användaren 
med anskaffning, lagring och spridning av information för ett kontinuerligt beslutstagande. 
Detta tycker jag att IT-systemet uppfyller (även om informationen i vissa fall inte stämmer) så 
viljan finns, men det som totalt missats är att göra funktionerna användbara. 
Systemleverantören X verkar bara ha sett till funktionaliteten, men att de funktionerna sedan 
är krångliga att använda har inte uppmärksammats. Det är faktiskts så att systemutvecklama 
inte är experter på arbetsuppgifterna även om det är ett branschsystem. Och det som är 
användbart för en målgrupp är inte användbart för en annan, menar Jayaratna. 

En stor mängd av den information som IT-systemet handhar är felaktig och detta kan i det 
långa loppet göra att förtroendet för att använda de nya funktionerna avtar. Därför att fungerar 
inte de viktigaste funktionerna utan att de måste korrigeras, varför då ödsla energi på 
ytterligare funktioner? Jayaratna menar att producera tillförlitlig information är en sak, men 
att samtidigt bidra med lärandemöjligheter är en helt annan. Det är viktigt att användaren kan 
påverka, godkänna och se nya möjligheter med funktionerna för informationsproducerandet. 

Vid intervjuer (sammanställningen bilaga 1) framkom det hos målgrupperna verkmästarna 
och kundmottagarna att det fanns funktioner som de inte visste vad de skulle användas till. 

Det överensstämmer med vad Wickens m.fl. (2004) menar med ”creeping features”, att 
mjukvaruföretag strävar efter att bygga in så många funktioner som möjligt för att mjukvaran 
ska var så användbar som möjligt. Men resultatet blir att ju fler funktioner desto svårare att 
designa ett gränssnitt som ger användarkvalitet. 

Jag upplever att resultatet är trovärdigt även om jag inte har gjort några mätningar, utan bara 
gått på respondentemas uppgifter och mina egna observationer. Det som gör kriterierna till så 
bra utvärderingspunkter är att definitionen av användbarhet blir kon kr et och ger en möjlighet 
att diskutera användbarhet med gemensam förståelse för begreppet. ISO-definitionen 
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inbegriper fler av de väsentliga aspekter som är viktiga för användarna än vad som oftast 
avses när man diskuterar användbarhet menar Gulliksen & Göransson (2002) Men detta är 
bara en del av användbarheten. Synsättet implicerar också att det finns ett underliggande 
förhållningssätt, en process. Användbarhet enligt ISO:s definition är ett betydligt vidare 
begrepp än det som användbarhet betraktas i dagligt tal. Användbarhet innefattar hela 
systemets spännvidd ur användarens perspektiv vara från funktionalitet till upplevelser av de 
etiska värdena. Därför tycker jag att valet av dessa kriterier känns trovärdiga i en målbaserad 
utvärdering. 

Men eftersom IT-systemet är uppdelat i olika målgrupper så måste det ses utifrån respektive 
arbetsuppgift. Om man då ser på användbarhets begrepp utifrån vad det internationella 
begreppet ISO 9241-11 pekar på (Gulliksen & Göransson, 2002): 

Den utsträckning till vilken en specificerad användare kan använda en produkt för att uppnå 
specifika mål, med ändamålsenlighet, effektivitet och tillfredställelse, i ett givet sammanhang. 
Ändamålsenlighet definieras som noggrannhet och fullständighet med vilken användarna kan 
uppnå givna mål. Ja, alla målgrupper kan lösa sina arbetsuppgifter och det fullständigt, men 
visa kan inte göra det med noggrannhet i vissa fall. Då menar jag att information om bil och 
ägare uppgifter inte stämmer. E kon om i modul en har problem med att avskrivnings summor 
och leveransansvarig har problem med att de automatiserade sälj dokumenten tappar 
information. 

Vidare effektivitet definieras som resursåtgång i förhållanden till den noggrannhet och 
fullständighet med vilken användarna uppnår givna mål. Här är det bara servicemarknad som 
uppnår det. Sedan följer målgrupper: lager, ekonomiavdelning, leverans och verkstad, egen 
mekaniker och kundmottagning detta beror på att systemet inte genererar rätt information om 
ägare, bil och rabatter utan mycket extra tid läggs på att säkerställa att arbetsordern och 
sedermera fakturan innehåller rätt information. Detta resulterar i att mottagning av kunder och 
fakturering bidrar till en försämrad effektivitet i verksamheten. 

Sedan är det då tillfredställelse som definieras som följande; frånvaro av obehag samt positiva 

o 

attityder vid användningen av en produkt. Återigen är det servicemarknaden som ligger i topp, 
där efter ekonomiavdelningen, lager och leverans medan kundmottaning, verkstad och egen 
mekaniker uppger att de känner frustration och stress för att informationen inte stämmer och 
att det tar så lång tid att utföra vissa moment. Detta påverkar i slutändan den kund som står 
och väntar. 

Den sista definitionen är användningssammanhanget som; användare, uppgifter, utrustning 
(maskinvara, programvara och annan material) samt fysisk och social omgivningen i vilken 
produkten används. Av min tolkning är det återigen servicemarknad och ekonomiavdelningen 
men även lager och leverans upplever sig tillfreds i det sammanhang de utför sina 
arbetsuppgifter. Kundmottagning, verkstad och egen mekaniker upplever mest frustration 
p.g.a. att de samtidigt ska utföra andra uppgifter och systemet är en del av arbetsuppgiften. 
Den egna mekaniker upplever att systemet tar 75 % av arbetstiden och mekande som ska vara 
den största delen endast får 25 % . Verkmästaren menar att de varje eftermiddag måste stänga 
in sig för att hinna fakturera det tar alldeles för lång tid. Även om en kund kommer och vill 
diskutera en gjord reparation eller service så måste verkmästaren gå in i systemet för att se 
vem som utfört jobbet trots finessen med tidsstämpling. Detta medför att en dator först måste 
uppsökas innan rätt mekaniker kan tillfrågas, vilket tar tid. 
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8.5 Utvärdering med kriteriebaserad utvärdering 

Problemsituation före 

Jag valde metoden för att utvärdera respektive målgrupps gränssnitt i användning med 
respektive användare. Jag tycker det är viktigt att utvärderingen genomförs tillsammans med 
respondenten för att fånga dennes uppfattningar om gränssnittet. 

Metoden utgår från tio kvalitetspunkter och hela koncentrationen ligger på användarens 
gränssitt. Metoden väljs för att utvärdera om system är handlingsbart. Det går att välja andra 
utvärderingspunkter om man så vill. Metoden kräver endast att man sitter vid datom och går 
igenom de olika punkterna antigen med användare eller utan. 

Metoden har inte några givna regler för hur man ska bedöma om idealen är uppfyllda eller 
inte. Metoden ger inte heller någon rekommendation för hur svaren ska dokumenteras. Jag 
valde att kategorisera svaren efter dessa: 

• Om kriteriet är uppfyllt eller inte 

• I viken grad kriteriet är uppfyllt 

• På vilket sätt kriteriet är uppfyllt 

Eftersom det inte finns någon given ram för hur det är tänkt att dokumentera utvärderingens 
resultat, har jag valt följande sätt: 

Uppfyllt = Då anser jag att kriteriet är uppfyllt, alltså inga påpekanden har framförts av 
respondenten eller något framkom under observation. 

Delvis uppfyllt = Då anser jag att det bara till hälften är uppfyllt alltså det finns ett eller två 
påpekanden på kriteriet. Antingen så visade respondenten påpekandet eller så framkom det 
under utvärderingen av kriteriet. 

Ej uppfyllt = Då var inte kriteriet alls uppfyllt och det var till stor betydelse för 
respondentens arbetsuppgifter. 


Jag valde att genomföra kriterierbedömningarna efter respektive kontextuell intervju med 
respondenterna. 


Problemsituation under 

Metoden kräver inga förkunskaper, så det är bara att läsa frågorna för användaren som då ska 
svara om det stämmer eller inte. Men det gäller att kunna förklara innebörden för 
respondenters som inte direkt förstår vad som menas. 

Det är viktigt att man sitter vid datorn när respondenterna ska svara på frågorna för om det 
behövs kan de visa vad de menar. Jag ställde nedanstående frågor och de svarade eller visade 
på skärmen om det var uppfyllt eller ej (Cronholm & Goldkuhl 2003): 

1. Enkelt kan förstås vad som kan göras med systemet (tydlig handlingsrepertoar) 

2. Kan ”sägas” det man vill genom systemet (tillgodose kommunikationsbehov) 

3. Enkelt kan ta sig till önskad plats i systemet (lättnavigerbar) 
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4. Förstår konsekvenserna av föreslagna och utförda handlingar (handlingstransparant) 

5. Direkt se att det man försökt göra blev gjort (feedback) 

6. Enkelt få hjälp att veta vad som gjorts (tydligt och lättåtkomligt handlinsminne) 

7. Vet vem som sagt vad (”personifiering”) 

8. Förstår använda begrepp (känd och begriplig vokabulär) 

9. Förstår kommunikativ avsikt med olika medelanden 

10. För ett bra stöd för handlande i verksamheten 

Metodens kvalitetsideal gick inte att framföra utan en omformulering så att respondenten 
förstod vad jag menade. Respondenten var tvungen att få en förklaring om vad som menades 
med idealet. Jag fick anpassa förklaringarna efter respektive respondent och metoden kändes 
alltmer otymplig med alla förklaringar för att få det begripligt för respondenten. 
Respondenterna missuppfattade ibland min förklaring och svarade på något helt annat. Detta 
kan givetvis bero på mig. Men jag känner spontat att denna kombination genomförs bäst utan 
användare. Att jag valde metoden beror på att jag ville ha en metod som utvärderade 
gränssnittet. 

Jag prövade även på en respondent från servicemarkand som var SuperUser/expert men inte 
heller denna expert förstod vad jag menade, utan att jag fick förklara. 

Problemsituation efter 

Metoden blev komplicerad att använda. Det var svårt att hela tiden omformulera respektive 
kvalitetsideal så att respondenterna förstod vad jag menade. Det kändes inte bra att använda 
ett sådant språk som respondenter inte kände igen. Det var helt otänkbart att ställa frågorna 
rätt ut eftersom de inte förstod vad jag menade. De måste omformuleras efter respektive 
respondents erfarenhet och datamognad. Det finns en stor risk att respondenterna känner sig 
dumma som inte förstår vad utövaren menar och detta kan resultera i att fel svar ges om inte 
utövaren är uppmärksam. Det gäller även att utövaren förstår innebörden av kvalitetsideal. 

Metoden ska visa om ett IT-system är handlingsbart, men det hänger mycket på att 
metodanvändaren kan formulera och säkerställa att respondenterna förstår frågan. 

Jag valde att sammanställa alla svar i en tabell så de skulle bli överskådligare, se tabell 4. Hela 
utvärderingen kan ses i bilaga 1, efter respektive intervjusammanställning. 

Metoden visar att målgrupperna servicemarknad, lager och ekonomi har högst uppfyllda 
kriterier, medan kundmottagning och verkstad har lägst. 
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Tabell 4, Resultat kriteriebaserad utvärdering 



Service¬ 

marknad 

Ekonomi 

Lager¬ 

ansvarig 

Kund¬ 

mottag¬ 

ning 

Leverans¬ 

ansvarig 

Verkstad 

Antal 

upp¬ 

fyllda 

Tydlig handlings- 
repertoar 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

Delvis 

uppfyllt 

3 st 

Tillgodose 

kommunikations¬ 

behov 

Uppfyllt 

Ej 

uppfyllt 

Uppfyllt 

Ej 

uppfyllt 

Uppfyllt 

Delvis 

uppfyllt 

3 st 

Lättnavigerbar 

Uppfyllt 

Uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

2 st 

Handlings- 

transparant 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Delvis 

uppfyllt 

Uppfyllt 

Uppfyllt 

5 st 

Feedback 

Uppfyllt 

Delvis 

uppfyllt 

Uppfyllt 

Delvis 

uppfyllt 

Ej 

uppfyllt 

Delvis 

uppfyllt 

2st 

tydligt och 

lättåtkomligt 

handlinsminne 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Ej 

uppfyllt 

4 st 

Personifiering 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Uppfyllt 

Delvis 

uppfyllt 

4 st 

Känd och 

begriplig 

vokabulär 

Ej 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

0 st 

Förstår 
kommunika- 
tiv avsikt 
med olika 
medelanden 

Uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Ej 

uppfyllt 

Uppfyllt 

2 st 

För ett bra stöd 
för handlande i 
verksamheten 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Delvis 

uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

Ej 

uppfyllt 

0 st 

Summa % 

80 % 

50 % 

60 % 

40 % 

20 % 

20 % 



Översikt över egna lösningar under metodens såns 

Egen kategorisering av utvärderingskriterier och hur de skulle dokumenteras. 
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8.5.1 Analys och diskussion utifrån Ramverket 

Jag har valt att analysera och diskutera problemsituationen före, under och efter 
tillsammans. 

Problemsituation 

Metoden ska hjälpa utövaren att fastslå om IT-systemet är handlingsbart. Metoden kan utgå 
från olika kvalitetsideal, checklistor eller principer. Det är upp till utvärderaren att välja. Det 
är även upp till utövaren om den ska göras tillsammans med användare eller inte. Metoden 
kräver ingen teknisk kompetens från utövaren utan den kan användas utan förkunskaper. 
Metoden problemdefinition är i en kombination av tekniska/funktionella termer. Det kräver 
att utövaren förstår och är på att förklara de olika kriterierna så användaren som ska svara på 
kriterierna förstår vad som menas. Metoden ger endast svar på ställda kriterier vilket inte kan 
ses som en lösning på ett organisationsproblem eller på hur väl de mänskliga kognitiva 
processerna stöds. Min uppfattning är att metoden bör användas som komplement till andra 
metoder och inte tillsammans med användare. 

Resultatet av utvärderingen visar att systemet är mest handlingsbart för servicemarknad med 
80 % av kriterierna uppfyllda. Därefter är det lager på 60 % och ekonomi på 50 %, sedan 
kommer kundmottagning på 50 % och sist är leverans och verkstad på vardera 20 %. Det som 
är intressant med detta resultat är att det påvisar som processutvärderingen att det är 
stödprocesserna som har störst handlingsbarhet och huvudprocessen minst. Dessutom visar 
även denna utvärdering att servicemarknad är den målgrupp som är bäst tillgodosedd i 
systemet. 

Enligt Jayaratnas krav på stöd i problemlösningsprocessen så upplever jag att metoden endast 
stödjer utövaren i första steget att förstå ”situation av intresse”. Därefter får utövaren göra 
egna antaganden f att förbereda diagnosen och definiera prognosen. P.g.a. för kvalitetsidealen 
är svåra att kommunicera med användarna så blir det svårt att skapa ett ömsesidigt deltagande. 
Jag tycker att min egen lösning att dokumentera idealen och bedöma om de var uppfyllda, 
eller fungerade inte bra. 


Metodutövaren 

Metoden kräver ingen kunskap eller erfarenhet från utövaren. 


Metoden 

Metoden fokuserar endast på de valda kriterierna. Metodens kvalitetsideal känns inte 
konstruerade för att använda praktiskt. Kvalitetsidealen som ska ställas till användaren är 
svårförståeliga för användaren. Det gör att utövaren måste omforma kvalitetsidealen så 
användaren förstår innebörden och kan svara. Därför känns hela metoden utformad för 
forskare och inte för att använda i praktiken. Jag ser en risk att en utövare kan få 
respondentema att känna sig dumma om de inte förstår vad som menas med kvalitetsidealen. 
Detta i sin tur kan medföra fel svar och i slutändan en felaktig utvärdering. 

Tack vare de svårförklarade kvalitetsidealen blir metoden tungrodd, och det är lätt att 
missförstånd uppstår mellan utövare och användare då användaren vill vara så behjälplig som 
möjligt i utvärderingen. Metoden hade varit enklare att utföra utan användare och då endast av 
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utvärderaren. En annan av metodens svagheter är att den inte utvärderar de kognitiva 
processerna (kort - lång minne, syn etc.) 

Metoden saknar regler/stöd för hur kriterierna ska dokumenteras och kategoriseras. Detta 
ansvar läggs helt på utövaren att hitta en bra lösning. Metoden ser inte hur arbetsprocessen är 
bakom gränssnittet utan fokus ligger på hur systemet svarar på arbetsuppgifterna som utförs. 
Den uppmärksammar därför inte hur arbetet utförs utan bara vad systemet ger för feedback på 
utförda moment. 


8.5.2 Teoribaserad analys och diskussion utifrån IT-systemets funktioner 

Här genomförs en analys och diskussion utifrån teorikapitlet informationssystem och 
användbarhet. 

Ett IT-systems funktioner är viktiga och det gäller att få dessa användbara oavsett målgrupp. 
Jayaratna (1994) menar att många praktiker kanske inte känner igen alla funktioner i 
organisationen. Olika målgrupper har olika behov och krav därför är det viktigt att inte bara 
utgå från en enskild målgrupps behov utan studera samtliga som ingår i verksamheten . 
Funktioner som passar bra för en målgrupp eller användare kan vara helt fel för andra 
målgrupper eller användare. Därför är det viktigt att det övervägande hänsynstagandet tas 
utifrån de olika verksamhetsmässiga omgivningarna av funktioner. Men den kriteriebaserade 
metoden gör ingen sådan utvärdering utan är mer en generell utvärdering av gränssnittet 
oavsett målgrupp eller användare. Ändå är resultatet intressant eftersom hos 
målgruppen/användare servicemarkand är hela 80 % av kriterierna uppfyllda medan hos 
målgrupperna kundmottagning och verkstad är endast 20 % uppfyllda. Återigen visar en 
metod att servicemarknad är den målgrupp som IT-systemet stödjer mest och kundmottagning 
och verkstad minst. 

De kriterier som inte var uppfyllda för någon målgrupp var ”få ett bra stöd för handlande i 
verksamheten” och ”känd och begriplig vokabulär”. Resultatet med avseende på det 
sistnämnda kriteriet är oroväckande utifrån att systemet är ett branschsystem och leverantören 
borde ha kunskap om branschen. Jayaratna (1994) menar att är viktigt att förstå den domän 
som informationssystemet verkar inom, för genom den insikten blir förståelsen för 
organisationskontexten klarare. Det ger även nödvändig kunskap för att analysera och 
diskutera funktionernas relevans i informationssystemet. Men även kriteriet att få ett bra 
handlande för sin arbetsuppgift borde leverantören ha en god kännedom om, men utvecklarna 
är inte experter på de arbetsuppgifter som utförs av användarna. Därför utvecklarna vet inte 
vilka beslut som kommer att tas på den information som IT-systemet producerar, det kan 
endast användarna göra. Detta medför att användarna bör involveras innan beslut tas för 
vilken information som behövs eller inte. 

Det kriterium som är mest uppfyllt är handlingstransparens, vilket visar på att respondenterna 
förstår vad som händer i systemet och vad som gjorts. Det näst mest uppfyllda kriterierna är 
tydligt och lättåtkomligt handlingsminne, och personifiering. En tydlig historik har saknats 
och upplevdes som positivt av respondenterna. 

Om nu metoden påvisade positiva och negativa konsekvenser för utvärderaren, hur går man 
sedan vidare och åtgärdar dessa konsekvenser? Det problem jag ser är att det inte bara går att 
lämna över utvärderingsresultatet till en interaktionsdesigner och att den ska förstå vad som 
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måste åtgärdas. Visserligen skulle man kunna komplettera utvärderingsresultatet med olika 
åtgärdsförslag för varje målgrupp. Men det jag menar är att kriterierna är svåra att 
kommunicera även för mig själv. 


8.6 Utvärdering med Kostnad - Nytto - Analys 

Problemsituationen före 

När en verksamhets arbetsuppgifter datoriserats är meningen att det ska bli effektivare eller att 
arbetsuppgifter kan rationaliseras bort. Ottersten & Balic 2004 påpekar det sällan görs någon 
uppföljning av om IT-systemet verkligen skapar någon effekt som utlovats. Därför vill jag ha 
med metoden kostnad - nytto - analys bland mina metoder. Jag vill avsluta utvärderingen 
med att granska vilka nyttoeffekter det nya systemet har skapat för målgrupperna och 
verksamheten. Jag har valt att se på IT-system ur ett tjänsteperspektiv och kommer därför 
även göra en uppskattning av vilken nytta verksamhetens kunder får. 

Jag kommer att göra bedömningar utifrån positiva och negativa effekter på respektive 
målgrupps arbetsuppgifter. Mina bedömningar kommer att göras utifrån intervjuunderlaget 
och från respondenternas upplevelse av det nya IT-systemet. Mina bedömningar är även från 
de tre metodemas (mål- och kriteriebaserade samt processmodellering) utvärderingsresultat. 

Visst finns det en risk för subjektiva bedömningar från respondenter men jag bedömer att 
risken inte är så stor då jag kan ställa bedömningarna mot varandra 

Jag kommer att titta på tidsvinster i form av automatiserade rutiner. 

Problemsituation under 

Det krävs en förståelse för ekonomiska beräkningar och uttryck för att göra dessa antaganden 
i utvärderingen. Min egen kunskap är gymnasieekonom med påbyggnadskurser på högskola. 
Jag har under arbetsgång med de andra metoderna uppfattat tidsvinster och tidsförluster men 
nu ska det även framställas i trovärdiga siffror. 

Jag bestämde mig för att utgå från respektive målgrupp. IT-systemet har bra funktioner som 
ska bidra till att skapa tidsvinster, men eftersom vissa funktioner inte fungerar som planerat, 
bidrar det istället till tidsökningar och interna och externa felkostnader. Dessa kommer att 
uppskattas i ökning respektive minskning av produktionen. 

Problemsituation efter 

De tre andra utvärderingsmetoderna tillsammans och intervjuerna(bilaga 1) gav ett bra 
underlag för att göra antaganden utifrån. Vidare var det viktigt att få grepp om hur många 
kunder man tog emot och hur många fakturor som skrevs. 

Vissa antaganden fick göras av tid och antal men genom att dessa antaganden redovisas öppet 
kan de kritiseras. Det som ekonomerna menar är att de indirekta kostnaderna ökar när vissa 
moment måste göras eller att ett moment kräver ytterligare tid för att momentet ska fungera. 
Eftersom jag grundar mina uppskattningar på respondenternas upplevelser och att det är flera 
som upplever samma sak så känns de trovärdiga. 

Det har inte gjorts några tidsmätningar, utan underlaget bygger på utvärderingsresultatet från 
processmodellering, målbaserad och kriteriebaserad utvärderingar samt på de intervjuer som 
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gjorts, (se bilaga 1, och 2) Det är respondentemas egen upplevelse av vissa moment som nu 
tar längre tid respektive kortare tid i det nya IT-systemet. 

Det ska förtydligas att faktureringen som nu till största delen görs av verkmästarna från början 
var tänkt att kundmottagarna skulle göra. Verkmästarna skulle bara behöva redigera, ev. 
komplettera, fakturan. Kundmottagaren skulle vara den som skrev ut fakturan till kunden. 
Detta fungerade inte p.g.a. att kundmottagarna inte kommer åt tidsstämplingen. 
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KUNDMOTTAGNING 


Positiv effekt 

Negativ effekt 

• Enkel kreditfakturahantering (intervjuer, 
processmodellering) 

• Enkel historikhantering (intervjuer, 
kriterieutvärdering bilagal, 
processmodellering) 

• Enkelt skapa servicepaket.(intervjuer, 
processmodellering) 

• Enkelt kunna ge kunden information om 
status på inlämnad bil (intervjuer) 

• Att det ej snabbt/enkelt går att ta fram en 
förståelig prisinformation till kunden 
(enligt konsumentverkets regler) 
(intervjuer, kriteriebaserad bilaga 1, 
målbaserad bilaga 2, processmodellering 
) 

• Att det ej går snabbt och enkelt att ändra 
eller uppdatera felaktig information om 
kunden och bil. (intervjuer, 
kriteriebaserad, målbaserad bilaga 2, 
processmodellering) 

• Att IT - systemet inte kan spara 
arbetsordema utan de måste förvaras i en 
låda. (intervjuer, processmodellering) 

• P.g.a. att information inte stämmer och 
uppdateras så måste uppgifter 
kontrolleras via CBR vilket kostar 2,50 
kr per förfrågan, (intervjuer, 

proces smodellering) 


De positiva effekterna och dem förväntade nyttan uteblir p.g.a. de negativa effekterna som 
uppstår för kundmottagama. Det går åt mer tid att försöka ge kunden en korrekt prisuppgift. 
Att snabbt och enkelt skapa arbetsodrar förloras när kunddata inte stämmer. Det går enkelt att 
uppdatera uppgifter men uppdateringen går inte igenom, utan hela arbetsordem måste 
avbrytas och göras om. Detta skapar en ökad tidsåtgång när samma moment måste utföras två 
gånger. 

T.ex. om varje kund normalt ska betjänas på 5 minuter. Men eftersom det nu tar 1 Vi minut 
extra att plocka bort poster som kunden inte ska betala från prisuppgiften. Men att dessutom 
även ägna ytterligare 3 minuter till att förklara varför det ändå står summor kvar som inte är 
giltiga på arbetsorder. Det skapar då 4 Vi minuter extra på varje kund, vilket innebär att 
kundbetjäningstiden har ökat i det nya IT-systemet från 5 minuter till 9 Vi minut per kund. 

Detta medför att kundgenomströmningen har minskat i det nya IT-systemet och då även 
produktiviteten eftersom längre tid får läggas på varje kund. Det kan också medföra en stress 
som minskar merförsäljningen. 
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VERKSTAD 


Positiv effekt 

Negativ effekt 

• Enkelt kunna ge kunden information om 
status på inlämnad bil. (intervjuer) 

• Se historik (kriteriebaserad bilaga 1) 

• Skapa kreditfaktura (intervjuer, 
processmodellering) 

• Det har blivit omständligare att skapa en 
förståelig faktura. Det är lätt att tappa 
information vid redigering. Dessutom 
svårt att se vilken/vilka de instämplade 
mekanikerna har varit. Att ge rätt rabatter 
är svårt, (intervjuer, kriteriebaserad 
bilaga 1, processmodellering) 

• Att inte kunna lita på att informationen 
om bil och kund är tillförlitlig (intervjuer, 
målbaserad bilaga 2, processmodellering) 

• P.g.a. att information inte stämmer och 
uppdateras, så måste uppgifter 
kontrolleras via CBR, vilket kostar 2,50 
per förfrågan, (intervjuer, 

proces smodellering) 


De positiva effekterna och den förväntade nyttan uteblir även för verkmästarna, därför att 
faktureringen inte fungerar som tänkt med att kundmottagaren skulle göra faktureringen. Ett 
problem är att arbetskostnaden och reservdelar kommer in oredigerat på fakturan. Posterna 
måste alltså delas upp för att det ska bli överskådligt. Samtidigt går det inte att få en 
helhetsbild av fakturan, utan bilden måste scrollas. Det är också lätt att tappa information vid 
redigering och det gäller både reservdelar eller utförda arbeten. Verkmästarna lägger färdiga 
fakturor i en korg som sedan hämtas av kundmottagaren. Skulle det vara något fel på fakturan 
exempelvis fel rabatter, då är det kundmottagaren som gör om hela fakturan igen. 

Fakturering ger verkligen en ökad indirekt kostnad form av dubbelarbete med fakturor som 
skrivs ut av verkmästarna och vid fel måste skrivas om av kundmottagarna. Det kan alltså i 
vissa fall vara så en faktura kan belasta två lönekostnader istället för en. 

Den ineffektiva faktureringen har gjort att verkmästarna avsätter fyra timmar varje dag för att 
fakturera. Det är tillsammans åtta timmar som verkmästarna varje dag utför fakturering på. 

De påtalade att de ”låser in sig”. Verkmästarna ska stödja mekanikerna vid felsökning etc. och 
kundmottagama när det gäller specifik rådfrågning till kunder som ringer. Detta skulle då 
innebära att mekanikerna inte får någon hjälp på eftermiddagarna, vilket i sin tur kan medföra 
att vissa moment stannar av och ställs åt sidan. En kund som ringer och vill ha specifik 
rådgivning måste återkomma när verkmästarna har tid. 

Jag bedömer verkmästarnas arbetssituation som väldigt utsatt eftersom de utför 
arbetsuppgifter som de inte är tänkta att göra, som dessutom tar mycket tid ifrån de 
arbetsuppgifter de är experter på att utföra. De ska även stödja andra målgrupper men detta får 
stå tillbaka för faktureringen. 
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VERKSTAD 


Positiv effekt 

Negativ effekt 

• Enkelt kunna fakturera (intervjuer, 
processmodellering) 

• Snabb/enkel kreditfaktura 
hantering(intervjuer, målbaserad bilaga 

2, processmodellering) 

• Faktura kan innehålla flera bilar och 
delas upp på flera intressenter. 

(intervjuer, målbaserad bilaga 2 
processmodellering) 

• Vid uppdateringar av IT-systemet tappas 
beskrivande texter i gränssnittet. 

Dessutom är gränssnittets förklarande 
text svår att läsa p.g.a. små teckensnitt, 
(intervjuer, målbaserad bilaga 2, 
kriteriebaserad bilaga 1, 

proces smodellering) 

• Den automatiserade rutinen mellan 
säljare och leveransansvarig tappar 
information och måste kontrolleras 
manuellt, (intervjuer, målbaserad bilaga 

2, kriteriebaserad, bilaga 1, 

proces smodellering) 

• Högre pappersförbrukning (intervjuer) 


I det nya IT-systemet har den manuella processen med säljdokumentet datoriserats, vilket 
innebär att säljaren nu fyller i ett säljdokument som sedan leveransansvarig mottager för 
vidare bearbetning. Detta moment var tidigare tidsödande. Men det som var tänkt att minska 
tidsåtgången har istället ökat tidsåtgången p.g.a. att systemet tappar information vilket gör att 
leveransansvarig ändå måste gå igenom dokumentet och kontrollera all information. 

Fakturering har effektiviserats av det nya IT-systemet genom att en faktura nu kan innehålla 
flera bilar och delas upp på flera intressenter. Detta gick inte i det gamla systemet utan där var 
det en faktura per intressent. Även att skapa en kreditfaktura har blivit enklare mot i det gamla 
systemet som i vissa fall krävde ändring med skrivmaskin. Detta sammantaget skapar 
tidsvinster vilket medför högre produktivitet. 

Den minskade tidsåtgången kan beräknas t.ex. så här: Om det i det gamla systemet tog 10 
minuter att skapa en faktura. P.g.a. att fakturan var på flera bilar så krävs det då en faktura per 
bil, vi lk et blir 10 minuter per bil. Det nya systemet bidrar till en tidsminskning då alla bilar 
kan läggas på en faktura. En riktig tidsvinst blir det för kreditfakturan som nu görs direkt i 
systemet med en enkel markering i en textruta. 

Gränssnittet påverkar produktiviteten negativt eftersom det vid uppdateringar tappar 
informationstext vilket medför att felaktig data kan inmatas. Teckensittstorleken i gränssnittet 
är så liten att misstag kan göras genom att nollor och åttor kan förväxlas. 

En högre pappersförbrukning bidrar till att kringkostnadema stiger. 
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EKONOMI 


Positiv effekt 

Negativ effekt 

• Det går enkelt att ta fram 
försäljningsstatistik och andra 
beslutsunderlag för snabba viktiga 
beslut, (intervju, målbaserad bilaga 2, 
processmodellering) 

• Vissa bokföringstransaktioner utförs inte 
på ett tillförlitligt sätt, utan måste 
kontrolleras manuellt, (intervju, 
målbaserad bilaga 2, kriteriebaserad 
bilaga 1) 

• Överföringen mellan ekonomisystem och 
System X fungerar inte, utan måste 
flyttas manuellt (intervju, målbaserad 
bilaga 2, processmodellering) 

• Det nya IT - systemet behandlar varje 
enskilt verifikat för sig, vilket medför att 
transaktionerna nu tar längre tid, en 
timme jämfört med det gamla IT - 
systemet. Detta sätt att behandla varje 
verifikat enskilt har även medfört att det 
är svårare att följa en transaktion om 
något blir fel. (intervju, målbaserad 
bilaga 2) 


Det nya IT-systemet bidrar till en effektiv hantering av beslutsunderlag, vilket ger tidsvinster 
och kan ge konkurrensfördelar. En ökad tidsåtgång har dock skapats p.g.a. att överföringarna 
mellan systemen inte fungerar, utan måste göras manuellt. Detta medför i sin tur att 
information kan bli fel eller missas. Dessutom stämmer inte vissa nedskrivningstransaktioner, 
som nu istället får beräknas manuellt. Detta skapar onödig manuell hantering som systemet 
skulle ha utfört, vilket leder till en ökad indirekt kostnad för arbetsmomenten. Det kan även 
bidra till psykologiska kostnader i form av att andra transaktioner inte heller stämmer. 


Att nu transaktionstiden har ökat med en timme och att det är svårare att följa en transaktion 
om något skulle bli fel ökar den indirekta lönekostnaden p.g.a. extra tidsåtgång. 

LAGERANSVARIG 


Positiv effekt 

Negativ effekt 

• Enkelt kunna skapa kreditfaktura 
(intervju, målbaserad bilaga 2) 

• Enklare flexiblare och snabbare 
sökningar av artikelfrågor (intervju, 
målbaserad bilaga 2, 
processmodellering) 

• Att ej enkelt kunna faktura effektiv 
t(intervju, målbaserad bilaga 2, 
proces smodellering) 

• Att inte effektivt kunna ta fram en 
prisfråga till kund (intervju, målbaserad 
bilaga 2, processmodellering) 


Stora tidsvinster har gjorts med det nya IT-systemet genom bättre sökbegrepp på artiklar, 
vilket skapar en positiv effekt. Men även lageransvarig har tidsförluster i samband med 
fakturering och prisfrågor, liksom kundmottagare och verkmästare. 
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SERVICEMARKNAD 


Positiv effekt 

Negativ effekt 

• Effektivt och enkelt kunna ta ut olika 
rapporter per användare etc. 
(processmodellering, intervjuer, 
kriteriebaserad bilaga 1, målbaserad 
bilaga 2) 

• Inga direkta tidsförluster kunde 

identifieras, (intervjuer, kriteriebaserad 
bilaga 1, målbaserad bilaga 2) 


Det nya IT-systemet har skapat en stor nytta och effektiviserat arbetsuppgifterna för 
servicemarknaden genom att man nu kan ta ut flera olika rapporter uppdelade på mekaniker 
etc. vilket inte alls gick att göra i det gamla systemet. Detta bidrar till att minska 
lönekostnaden för detta arbetsmoment. 


EGEN MEKANIKER 


Positiv effekt 

Negativ effekt 

• Enkelt kunna skapa kreditfaktura 
(intervju, processmodellering) 

• Att inte snabbt eller enkelt kunna ändra 
eller uppdatera felaktig information om 
kunden eller bilen och kunna lita på att 
informationen stämmer, 
(processmodellering, målbaserad bilaga 

2) 

• Att inte enkelt kunna fakturera, 
(processmodellering, målbaserad bilaga 

2) 

• Ej ledas fel vid plockningen av 
arbetsoperationer. (intervju) 

• P.g.a. att information inte stämmer och 
uppdateras så måste uppgifter 
kontrolleras via CBR, vilket kostar 2,50 
per förfrågan, (processmodellering) 


Det nya IT-systemet har skapat en effektivare kreditfakturahantering, vilket ger en avsevärd 
tidsvinst. Men fakturahantering försämras i det nya IT-systemet jämfört med det gamla 
systemet, p.g.a. av att information inte stämmer och moment måste göras om, mer 
information finns att fylla i, samt en svåröverblickad faktura. Ingen generering av fast 
information (i det gamla IT-systemet fanns snabbkommandon som generade fast information). 
Man leds lätt fel av gränssnittet när man är stressad, och det skapar också dubbelmoment. 
Sammanfattningsvis har dessa problem avsevärt ökat de indirekta kostnaderna för 
faktureringen. Dessutom kan även psykologiska kostnader påverka att mekanikern upplever 
att 75 % av tiden går åt till fakturering och 25 % till kunden. Som egen företagare blir dessa 
problem större än för de andra målgrupperna, som får sin lön i alla fall. 
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KUNDER 


Positiv effekt 

Negativ effekt 

• Det går snabbt att få en kreditfaktura om 
något är fel. 

• Det går snabbt att få reda på hur långt 
man har kommit på servicen 

(processmodellering, se kundmottagning) 

• Det tar längre tid att få en begriplig 
prisuppgift 

• Längre väntetid vid kundmottagningen 

• P.g.a. de svårigheterna med rätt 
information om kund, bil och rabatt 
uppgifter på arbetsorder kan kunden 
behöva lägga extra tid på att kontrollera 
eller rätta fakturan. 

• Det går inte att se vilken mekaniker som 
utfört service på bilen 

• Fakturor ser olika ut beroende på vem 
som har gjort den. 

(Dessa antaganden har jag gjort efter 

negativa effekter hos kundmottagning och 

verkstad) 


Det nya IT-systemet har gjort det enklare för kunderna att få besked om var i service 
processen deras bil befinner sig och en snabbare hantering av kreditfaktura. Men kunderna får 
dock längre väntetid vid kundmottagningen. De får även svårt att få en begriplig prisuppgift. 
Och hur stämmer egentligen informationen när gamla uppgifter kommer upp på arbetsordem, 
trots försök till uppdateringar? Detta gäller Men även de rabatter som ska ges och som inte 
stämmer. 

Detta kan bidra till fler missuppfattningar och misstroende mot att IT-systemet inte gör 
korrekta beräkningar. Detta skapar en tidsökning för kunderna som måste avsätta längre tid 
för att kontrollera prisuppgifter. Detta ger kunden en ökad indirekt kostnad , men även de 
psykologiska kostnaderna kan komma att öka för kontroll av rabatter och prisuppgifter. Detta 
får till följd att kunden känner sig orolig över huruvida fakturan kommer att stämma eller inte. 


8.6.1 Analys och diskussion av metoden utifrån Ramverket 

Jag har valt att analysera och diskutera problemsituationen före, under och efter 
tillsammans. 

Problemsituation 

För att göra beräkningarna eller antagandena för problem situationen krävs att någon annan 
metod har redovisat data som beräkningarna kan utgå från. Det krävdes också kompletterande 
frågor som de andra metoderna inte hade om dessa data. Metoden ger utvärderarens 
subjektiva bedömning av de insamlade datas kostnader och nyttor. Metoden i sig ger ingen 
lösning utan bara en information från de data som framtagits. 

Det var inte så svårt att uppskatta tidsvinster eller tidsförluster. Min ambition vara från början 
att göra beräkningar, men jag valde istället att bara beskriva mina antaganden av ökning 
respektive minskning. Detta p.g.a. att jag tror att de kan upplevas och tolkas på liknande sätt. 
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Jag bedömer utifrån Jayaratnas faser problemlösningsprocessen så att det är utövaren som ser 
”situationen av intresse”, och därefter måste utövaren förbereda och förstå diagnosen och 
problemen. Metoden ger bara information om vad som är kostnader och nyttor utifrån vad 
utövaren gör för bedömning. Det är viktigt att som utövare förstå ”situationen av intresse” för 
att utifrån denna se verksamhetens helhet när kostnader och nyttor ska tas fram. Utifrån 
utövarens mentala tankeskapelse definieras sedan problem och diagnos. 


Metodutövaren 

Det kan ses som hårt och positivistiskt att redovisa med siffror men jag har inte den 
uppfattningen utan ser det som ytterligare ett sätt att redovisa den empirin som framkommit. 
Givetvis måste utövaren redovisa sina antaganden så att de kritiskt kan granskas. Det är 
viktigt att metodens begrepp förstås av utövaren så det krävs kunskap eller insikt i 
ekonomiska begrepp. Givetvis kan uppskattningar uppfattas som subjektiva och blir därför 
olika med ol ik a utövare. Därför bör utövarens perspektiv granskas. Vidare tycker jag att det är 
viktigt med kostnadsberäkningar eftersom det i dag nästan alltid krävs eller förutsätts när nya 
satsningar ska göras på en produkt. Den som lyssnas på är den som har bäst ekonomiska 
argument att komma med. Eller se det tvärtom: hur har effekterna beräknats kan de 
ifrågasättas? 


Metoden 

När man ska använda kostnad - nytto - analys bör en utvärdering/analys göras så man vet vad 
som ska beräknas eller inte. Metoden förväntar sig att utövaren har den kunskap som krävs för 
ekonomiska beräkningar och begrepp. Dessutom krävs att utövaren är intresserad av att göra 
antaganden och beräkningar. Metoden förutsätter att man förstår verksamheten och dess 
kunder. Det är upp till varje utvärderare att besluta om vad eller hur beräkningarnas ska göras. 
Det som kan ses som ett problem är just begreppen ”Nytta” och ”Kostnad”, hur ska de 
definieras så alla inblandade förstår vad man menar? Vi har alla våra egna tolkningar och 
därför måste utövaren klart redogöra för vad begreppen står för just i detta sammanhang. 
Vidare bör varje förslag till förbättring ses i förhållande till sin kostnad. 

Siffror kan givetvis antas på olika sätt i likhet med kostnader och nyttor och uppfattas som 
subjektiva. Metoden stödjer sin utövare och dennes argument, och därför bör kund och ev. 
leverantör ställa frågan vilket är syftet som utövaren har med att redovisa siffror på detta sätt. 

Metoden förstår situationen av intresse som Jayaratna förespråkar. Det finns stöd för hur 
kostnader ska beräknas och hur de ska kategoriseras och antas. Men i varje utvärdering är det 
upp till utövaren att bedöma vad som ska antas och beräknas. 


8.6.2 Teoribaserad analys och diskussion utifrån ett ekonomiskt 
perspektiv 

Här genomförs en analys och diskussion teorikapitlet informationssystem och användbarhet. 

Jayaratna (1994) menar att det är viktigt att information som produceras används och i många 
fall gör det inte det, men kostnaden finns. Den information som produceras i detta 
utvärderingsfall kan i många fall inte användas rakt av utan måste kontrolleras mot kunderna. 
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o Q 

Detta skapar extra kostnader som inte uppmärksammas. Återigen är det malgruppema 
kundmottagning och verkstad som har mest extra indirekta kostnader i sina arbetsuppgifter. 
Detta är i form av att informationen inte stämmer och även om de ändrar och systemet 
bekräftar det så fungerar det inte, utan vissa arbetsuppgifter måste göras om från början. 
Givetvis har det kommit många nya smarta funktioner som bidrar till att spara tid, exempelvis 
kreditfaktura, historik, uppläggning av arbetsoperationer, snabbt se var en servad bil befinner 
sig i processen. Tyvärr är det dock stora brister i informationen och att många arbetsuppgifter 
upplevs ta mycket längre tid att utföra varför man har svårt att ta till sig det som fungerar bra. 

Visst kanske många uppfattar mina bedömningar som subjektiva, men man bör se till helheten 
och vad verksamheten verkligen ska leverera till sina kunder. Att påpeka att arbetssättet är 
generellt menar jag inte håller, för det kan inte finnas en företagsledning som vill att arbetet 
ska ta längre tid. Jayaratna pekar på en viktig insikt, att vi också måste ta hänsyn till andra 
intressegrupper som inte definierar problem på samma sätt. Har vi inte samma förståelse inför 
problemet så kommer det att innebära att vi inte löser problemet, eftersom vi har olika syn på 
problemet. Varje person uppfattar ”verkligheten” på olika sätt. Ibland är det inte tillräckligt att 
identifiera och lösa problem i den verkliga världen. Exempelvis om utvärderaren påvisar att 
arbetet är ineffektivt och det kommer att öka lönekostnaderna, och klienten svarar, det spelar 
ingen roll, eftersom lönerna är så låga i ett U-land. 

Vissa respondenter påpekar i intervjuerna (se bilaga 1) bl.a. servicemarknad och lager att det 
finns rapporter som de inte ser någon användning av, från och vad har det kostat att ta fram i 
utvecklingskostnader för bl.a. lönekostnad för utvecklaren? Det verkar stämma med vad 
Jayaratna påpekar att det finns forskningsundersökningar som visar att 47 % av de utvecklade 
funktionerna inte används. Samtidigt påvisade Wickens m.fl. att leverantörer strävar efter att 
bygga in så många funktioner som möjligt för att passa tänkbara situationer. Därför blir 
klyftan mellan användarnas behov och produktens efterfrågan helt beroende på produktens 
utformning. Det är majoriteten av användarbehovet som ska styra och inte den specifika IT- 
produkten, men likväl styr också organisationen och dess kultur utvecklingssituation av IT- 
produkten påpekar Mayhew (1992) och Wickens m.fl. (2004). 

o 

Återförsäljarna kan ses som ett tjänsteföretag vars bärande tanke bakom är 
relationsmarknadsföringen vilket de med sina kunder bygger upp långsiktiga relationer med, 
och erbjuder tjänster med hög och jämn kvalitet. Detta ska i sin tur leda till nöjda kunder, 
lojalitet och lönsamhet, menar Grönroos (1992). Att skapa och underhålla den relationen har f 
r kundmottagningen blivit avsevärt svårare. Det tar längre tid, är krångligt att ge en enkel 
prisuppgift, rabatter kan bli felaktiga, liksom uppgifter på bilar och kunder. Detta innebär att 
de indirekta kostnaderna ökar för kunderna och kundmottagaren. Kunderna måste lägga ner 
mer tid på att kontrollera prisuppgifter och faktura. Och kundmottagaren drabbas av klagomål 
och felaktigheter som ska rättas till, vilket kan ge övertidsarbete för att hinna med. 

Om man jämför målgrupperna så är det kundmottagning, verkstad och egen mekaniker som 
har störst indirekta kostnader i form av att extra tid måste läggas på att kontrollera att 
information är rätt. Dessutom har framtagning av prisuppgifter och fakturering blivit betydligt 
krångligare att utföra, vilket är en av de vanligaste arbetsuppgifterna. För övrigt arbetar dessa 
målgrupper närmast kunden och står för en stor del av relationsskapandet. 

Även för ekonomiavdelningen har vissa moment drabbats av risker och ineffektivitet. I och 
med att batchkörningen inte fungerar måste siffror plockas för hand mellan systemen, vilket 
kan bidra till att siffror tappas eller skrivs fel. Men även automatiserade funktioner som 
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avskrivning utförs inte på ett korrekt sätt. Detta bidrar till att andra moment också ifrågasätts 
och kanske dubbelkontrolleras, vilket leder till ökade indirekta kostnader men även 
psykologiska kostnader. Även leveransansvarig har drabbats av att den förväntade nyttan med 
automatiserade försäljningsdokument mellan säljare och ansvarige inte fungerar utan 
information tappas, vilket innebär att momentet måste kontrolleras manuellt. Alltså görs ingen 
tidsvinst och minskad lönekostnad utan ger istället en ökad lönekostnad och tidsförlust. Det 
målgrupperna har ändå fått effektiva funktioner, så som enklare kreditfakturering, historik, 
flera bilar/köpare per faktura, fler sökbegrepp etc. Dessa nya funktioner har gjort att många 
tidsödande moment har avskaffats, vilket har skapat positiva effekter för målgrupperna något 
som de verkligen har framhållit. 

Återigen så är det servicemarknad den målgrupp som inte drabbats av några extra indirekta 
kostnader. 

Jag ser inga direkta hinder för IT-systemet skulle kunna skapa en bättre användbarhet för 
respektive målgrupp. Målgruppernas engagemang att använda system är det inget fel på. 
Genom att genomföra en kartläggning av respektive målgrupp hos ett antal återförsäljaren 
skulle information snabbt insamlas för att åtgärda många av de upplevda problem och saknade 
effekter snabbt kunna åtgärdas. Jag håller inte med om att argumentet att det inte går, därför 
att det är ett standardsystem. Problemet ligger snarare åt att man tror det kostar för mycket, 
men hur mycket kostar alla de åtgärder som måste göras för att rätta till de problemen så att 
återförsäljaren ska bli nöjd? Dessa kostnader kunde istället ha lagts på en ordentlig förstudie. 

Produkter som leder till att användarna måste göra onödiga arbetsmoment och dessutom 
krånglar och det uppstår fel leder till låg produktivitet. Detta blir ett allvarligt problem om 
produkten används av många användare under en stor del av dagen. Detta ser jag som ett 
annat problem, som inte uppmärksammats fullt ut av återförsäljaren är att eftersom 
informationen om kund och bil inte stämmer i vissa fall så vågar respondenterna alls lita på 
uppgifterna utan kontrollerar via CBR att det stämmer. Dessa förfrågningar kostar 
återförsäljaren 2,50 kr för varje förfrågan som görs. Enligt ekonomiansvarig låg kostnaden 
förra året på 400 000 tkr, vissa förfrågningar är nödvändiga att göra, men kostnaden stiger när 
man inte kan lita på ägaruppgifterna. Ottersten & Balic, (2004) menar att effekten av 
oönskade kostnader i driftfasen uppstår om utvecklingen av ett IT-stöd inte styrs mot 
förväntade effekt och resultatuppföljning visar sällan eller aldrig någon av dessa kostnader 
som dessutom är dold. Även lönekostnader för personal som inte tillhör IT-avdelningen, men 
som ger stöd till användare kan även de räknas till dolda kostnader fast många tar det för givet 
att olika personal måste vara involverade. 
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8.7 Analys och diskussion av en kombination utifrån Ramverket 

Jag kommer här att föra en diskussion utifrån kombinationen av mina valda metoder. 
Utgångspunkten kommer som tidigare att ligga på problemsituationen före, under och efter 


8.7.1 Problemsituation 

Jag valde metoderna för att de har olika angreppssätt vilket jag menar är en styrka och oerhört 
viktigt för en utvärdering. Jayaratna (1994) menar att innan någon problemlösning ens kan 
göras måste en fördjupad förståelse ha skapats över den situation som råder mellan olika 
personers perspektiv på problemet. Just detta menar jag styrker mitt val av flera metoder för 
att säkerställa att problemet ses ur olika perspektiv. Jag ville utvärdera processflödena, 
funktioner och gränssnitt. Min egen erfarenhet är att en utvärdering oftast bara görs med en 
enda metod, t.ex. vid anskaffning av ett standardsystem så granskas bara vad systemet är 
ämnat för och därefter försöker man hitta ett standarsystem som har dessa funktioner som 
efterfrågas. Vid en gränssnittsutvärdering utgår man i många fall från olika kriterier och 
målgruppernas behov för att utvärdera hur effektivt respektive gränssitt är för målgruppernas 
behov. Kostnad - nytto - analys av nya funktioner är något som många tar för givet, dvs. att 
det ses som en självklarhet att ett nytt IT-system är effektivare än det gamla. Eller att man gör 
s.k. skrivbordsberäkningar om vilka rutiner som kan automatiseras och personalen minskas 
o.s.v. Jag menar att det inte är tillfredsställande att bara använda en enda metod därför att en 
utvärdering måste göras utifrån ett helhetsperspektiv och ses från verksamhetens 
kärnverksamhet och kunder. Därför är förhoppningen att denna kombination ska se till 
verksamhetens helhet och på ett genomgripande sätt utvärdera hur väl verksamheten kan 
uppfylla sina mål och på ett framgångsrikt sätt betjäna sina kunder, men samtidigt vara 
kostnadseffektiv och konkurrenskraftig. Jayaratna (1994) poängterar att en förnuftig 
problemlösare vill ha en ”god” förståelse för situationen och detta åstadkoms genom att 
problemlösaren noggrant genomlyst problemet från olika perspektiv, men även att jag själv 
har bearbetat det mentala tankemönstret. Detta tillsammans skapar en god förutsättning för 
den givna problemsituationen. 

Intervjuer och observationer har en stor betydelse för underlag till metoderna. Jag ser alltså 
stora fördelar i att i en problemsituation använda flera metoder, och eftersom varje metod har 
sin utgångspunkt så måste jag som utövare anta nya perspektiv och ifrågasätta mig själv. Just 
ifrågasättandet av sin egen tankeskapelse menar Jayaratna (1994) är viktigt för att öppna nya 
tankebanor och nya seenden, vilket skapar en förståelse för vad som karakteriserar våra 
känslor och beslutsfattande detta gör mig till en effektiv problemlösare. Men det känns först 
väldigt frustrerande när data som påträffades och var av stor vikt inte passade in i den metod 
som jag för tillfället arbetade med. Det skapade först en frustration, men efterhand lärde jag 
mig att notera viktig information, och föll inte för tanken att arbeta med metoderna parallellt. 

Det kändes naturligt att börja med processmodellering för att kartlägga IT-systemets 
processer, för att finna målgrupper, arbetsuppgifter och externa kunder. Att sedan med den 
målbaserade utvärderingen och ISO:s definition av användbarhet utvärdera hur effektivt 
målgrupperna kunden utför sina arbetsuppgifter. Medan den kriteriebaserade utvärderingen 
tog perspektivet handlingsbart och utvärderade gränssnittets aspekter. Att avsluta med kostnad 
- nytto - analys blev ett bra sätt att se vilka positiva respektive negativa effekter det nya 
systemet hade bidragit med jämfört med det gamla IT-systemet. 
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Jayaratna (1994) menar att för att problemlösaren ska bli effektiv måste en djupare förståelse 
för organisationen inhämtas. Jag upplever att en djupare förståelse skapas och gör det 
tydligare för mig som utövare att förstå problemsituationen när flera metoder används. Det 
tvingar mig som utövare att angripa problemsituationen på olika sätt, vilket gör att min 
mentala tankeskapelse måste ställas om för varje metod för att avgöra vilken information som 
måste inhämtas. Jag ser även fördelen med att den dragna gränslinjen ses ur olika perspektiv 
som Jayaratna (1994) menar är viktig för att identifiera relevanta element. 


8.7.2 Metodutövaren 

Att använda en kombination av metoder från olika yrkesområden och synsätt kan vara 
utmanande. För dem som inte är öppna för nya intryck och nya synsätt kan vissa av 
metoderna ses som ”sunt förnuft”. Jayaratna menar att våra förutfattade meningar begränsar 
oss. De formas av värderingar och erfarenheter utifrån osäkerhet och ovisshet som vi 
upplever. Det kan göra att vi inte ser nya möjligheter utan begränsar oss i vårt tänkande. 
Därför måste vi öppna upp och ta oss förbi detta mentala hinder. 

Att använda olika utvärderingsmetoder var för mig en klar fördel genom att tvingas byta 
perspektiv och se på IT-systemet på olika sätt. Givetvis är det upp till varje utövare att ha sitt 
perspektiv och sitt syfte med utvärderingen. Detta medför att man som utövare ser det man 
vill se och det bör man därför ha i åtanke (Jayaratna). Men att som metodutövare fokusera på 
de olika angreppssätten upplever jag gör mig fri i tanken och jag tvingas ifrågasätta mitt 
synsätt. Det bidrar till att min egen tankeskapelse utvärderas och jag får ifrågasätta mig själv 
och mina värderingar och synsätt som utövare. 

Vi utgår från att våra värderingar ska vara goda menar Jayaratna. Dessutom ligger dessa 
värderingar sedan till grund för bedömningar av situationer och beteenden vi iakttar. Just detta 
var oerhört intressant att upptäcka med mina valda metoder, hur de styrde in mig som utövare 
på olika aspekter som jag innan hade nonchalerat. 


8.7.3 Arbeta utifrån en kombination av metoder 

Att arbeta med flera metoder kan i början kännas frustrerande när man ser saker och den 
metod man jobbar med för tillfället inte bryr sig om detta. Men det är en fördel att arbeta med 
olika metoder som har olika perspektiv. Jag anser att alla fyra metoderna har sina brister men 
även styrkor. Genom att kombinera metoderna kan vissa brister som en metod har täckas av 
en annan metod. Dock fångade intervjuerna och observationen upp att det fanns funktioner 
som ingen använde. Nu var min tid ute hos återförsäljaren väldigt kort och det kan ifrågasättas 
om jag hunnit få med allt. Men jag upplever att min korta tid har varit lyckosam för 
utvärderingen. Jayaratna påpekar att blicken bör lyftas från problemområdet och även 
angränsade system bör ingå i utvärderingen. Men tidsaspekten för denna uppsats gjorde inte 
det möjligt. 

Att förstå en situation av intresse: Jayaratna påpekar hur viktigt det är att förstå 
problemsituationen och det tycker jag processmodelleringen gör. Genom att verkligen 
kartlägga ”vad som gör ’ och av "vem" så skapar det även en förståelse för dem som arbetar i 
processen. Metoden hjälper till att avgränsa områden, blottar flaskhalsar och onödiga 
moment. Metoden förbereder även en bra diagnos av ”idagprocessen” och 
”imorgonprocessen”. Den möjliggör en gemensam förståelse för problem och diagnos för 
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utövare och användare (bara om användarna är med vid kartläggningen annars skapas ingen 
förståelse hos användarna, vilket då kan uppfattas som att processer är något som läggs på 
dem uppifrån ledningen). 

Processmodelleringens styrka är bra diagnoser (idag- och imorgonprocesser), den visar 
flaskhalsar och onödiga moment och är ett bra sätt att skapa delaktighet på. Dess svaghet är 
att den inte utvärderar gränssnittskrav eller icke- funktionella krav och metoden kan bli 
väldigt rationell och endast utföras av en utomstående person, alltså metoden baseras helt på 
vem utövaren är. 

I samband med den målbaserade utvärderingen i att förstå en situation av intresse upplever jag 
att kombinationen med användbarhet enligt ISO 9242-11 blev lyckad. De tre 
utgångspunkterna: Ändamålsenlighet - i vilken uträckning klarar man uppgiften, Effektivitet 
- hur lång tid tar det att klara uppgiften och Tillfredsställelse - personligt tycke registreras 
med ett frågeformulär. Det var till en början en del tolkningsproblem som jag blev tvungen att 
definiera för att man skulle se hur jag hade bedömt vissa arbetsuppgifter. Jag utgick ifrån 
respondentemas upplevelser för att förstå deras situation och intresse och upplever att det blev 
ett lyckat resultat. Styrkan med metoden är att den är mätbar i tid och upplevelse. Dess 
svaghet är att fokus endast ligger på hur effektivt målgrupperna kan lösa sina arbetsuppgifter, 
men definierar inte vad som är problemet. Detta beror på att effektivitet och ändamålsenlighet 
är mätbara mål. 

Även den kriteriebaserade utvärderingen utgår från användarens situation och utvärderade 
systemets handlingsbarhet, vilket även den fokuserade på användbarhet men ur ett annat 
perspektiv och kompletterade därmed den målbaserade utvärderingen. Men metoden är 
alldeles för krånglig att använda tillsammans med användaren, eftersom varje kriterium 
kräver en förklaring vad som menas och det är lätt att användaren missuppfattar eller inte 
förstår och svarar fel. På så sätt kräver metoden fullständig uppmärksamhet och erfarenhet av 
utövaren att ge en bra förklaring till varje kriterium. Därför undrar jag om metodskaparen 
själv har använt metoden och förstått situationen av intresse. Metodens styrka är att den 
kompletterade den målbaserade utvärderingen eftersom den hade fokus på andra viktiga 
punkter som rör användbarhet. 

Kostnad - nytto - analys var för mig en självklarhet att det skulle ingå i min utvärdering. 

Även om jag inte gjorde den så omfattande som jag från början tänkt mig, så bidrar den till att 
kunna redovisa utvärderingsresultat i termer av nytta, tidsvinster, och tidsförluster. Detta är 
just styrkan med denna metod. Svagheten som metoden innehar är att den kräver djupare 
kunskaper inom ekonomi och att man bör ha en god förståelse för kärnverksamheten och 
kunna se till helheten. Dessutom kräver metoden förarbeten som processkartläggning och 
intervjuer. 

Det finns ingen metod som är perfekt, menar Jayaratna, för om så vore skulle utvecklingen 
avstanna och vi inte utvecklas. Jag påpekade tidigare att det är tidskrävande att arbeta med 
flera metoder, vilket kan ses som en nackdel. Däri kanske svaret ligger på varför många 
tycker att det räcker med en metod. Dessutom så är metoderna hämtade från olika 
yrkesområden som i många fall står i konkurrens till varandra i utvecklingsprojekt. Min 
förhoppning är att denna konkurrens kan övervinnas och att man tillsammans kan utveckla 
verksamhetens kärnverksamhet och en samordnad metoduppsättning. 

Processmodelleringen tar mycket tid och det är en fördel att vara flera som arbetar med 
framtagningen av processen. Den kriteriebaserade metoden var inte lätt att genomföra 
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tillsammans med användare, p.g.a. att det var svårt att förklara kvalitetsideal på ett lättfattligt 
sätt för respondenterna. Men det beror nog mer på kriterierna än på själva metoden. 

Jag ser det som en klar fördel att arbeta med de olika metoderna eftersom de har olika 
angreppssätt. En annan fördel är att metoderna har olika intressen för situationen. Detta menar 
jag bidrar till att eliminera lite av det Jayaratna menar att en svaghet med många metoder är, 
nämligen att tvinga användarna till att acceptera ett särskilt mentalt tillstånd. Här kan jag 
faktiskt bekräfta användarna i vissa tillstånd t.ex. att det nu tar längre tid att fakturera, och att 
det nu är krångligare att ge kunden en korrekt prisuppgift. Detta påvisar både metoden 
processmodelleringen och den målbaserade utvärderingen. Därtill påvisar alla metoder att 
målgrupper som kundmottagning och verkstad är de som har sämst stöd, medan 
servicemarknad är den målgrupp som IT-systemet stödjer bäst. 

Givetvis har varje metod sina svagheter och styrkor, men jag upplever ändå att de 
kompletterade varandra i problemlösningsprocessen. Jayaratna menar att det finns ingen 
modell eller teknik som är kapabel att fånga in den fulla komplexiteten i den givna 
situationen. Det stämmer väl in på min utvärdering, t.ex. hade jag inte fångat den starka 
gränslinjen mellan de olika yrkena utan intervjuerna och observationerna. Inte heller hade jag 
fångat funktioner som inte används av målgrupperna. 
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9 Slutsats 

Här redovisas jag de slutsatser som ska besvara mina frågeställningar utifrån utvärdering 
med en kombination av olika metoder på ett branschsystem. 

Vilka problem och styrkor finns med respektive metod? 

Processmodellering 

Den processbaserade metoden som jag valde för att kartlägga vilka processer som IT-systemet 
skulle stödja har den styrkan att den kartlägger flöden tvärs igenom organisationen. Den bryr 
sig inte om avdelningar eller hierarkier utan ser bara det som ger kunden tillfredställelse. Den 
kartlägger på ett effektivt sätt vad som görs och vem som gör vad, oavsett om arbetet är 
datoriserat eller ej. Detta bidrar till att alla övergångar mellan de olika funktionerna redovisas. 

Det problem jag ser med metoden är att den inte utvärderar något som avser icke-funktionella 
krav utan mer de funktionella. Detta kan leda till att en effektiv process kan bli ineffektiv 
istället om det rör ett IT-system. 

Målbaserad utvärdering 

Den målbaserade utvärderingen valdes för att utvärdera användbarheten enligt ISO 9242-11 :s 
(1998) kriterier. Styrkan med den målbaserade utvärderingen är att den kan utvärdera både 
kvalitativt och kvantitativt det är utvärderaren som väljer. Mitt val av kriterier gjorde att 
metoden på ett bra sätt kompletterade den kriteriebaserade utvärderingen, eftersom 
angreppssätten vara annorlunda. 

Det problem som kan upplevas med min valda kombination är att fokusen enbart ligger på hur 
effektivt användarna utför sina arbetsuppgifter. Den målbaserade utvärderingen kan kännas 
väldigt förvirrad i början eftersom den utgår helt från utövaren. 

Kriteriebaserad utvärdering 

Den kriteriebaserade en valdes för att utvärdera om IT-systemet var handlingsbart. Metodens 
styrka är att den utgår från olika kvalitetskriterier för ett IT-system oavsett 
målgrupp/användare när gränssnittet ska bedömdas. Den kompletterade den målbaserade 
utvärderingen på ett bra sätt. 

Ett problem med metoden är kvalitetskriteriena är alldeles för svåra att förstå för 
respondentema. Detta innebär att utvärderare måste lägga stor kraft på att förklara, och ge 
tydliga exempel för att respondentema ska förstå och kunna svara. Detta gör att metoden blir 
tungrodd att arbeta med och den delaktighet som jag ville uppnå med användaren minskas. 

Kostnad - Nytto - Analys 

Metoden kostnad - nytto - analys, var ett bra sätt att redovisa de positiva respektive negativa 
effekter som det utvärderade IT-systemet bidrog med. Metoden kunde till stora delar använda 
de andra metodernas data, men det krävdes kompletterade frågor som de andra metoderna inte 
fångade. 

Styrkan med metoden är att den påvisar indirekta kostnader som en praktiker annars inte 
tänker på. Den ger genom mjukdata ett sätt att redovisa kostnader och nyttor på. Vilket jag 
hoppas kan väcka praktikern till att verkligen reflektera över osynliga IT - kostnader och 
nyttor. 
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Att använda metoden kostnad - nytto - analys, fordrar kunskap att förstå olika specifikt 
ekonomiska begrepp och man måste se till hela verksamheten. Dessutom kan kostnad - nytto 
- analys upplevas som positivistisk. Det kan även vara svårt att föran kr a kostnad - nytta hos 
vissa praktiker eller forskare beroende på bakgrund, men även att det kan uppfattas som 
subjektiva bedömningar. 

Därtill kan upplevas som ett problem för praktikern är att det måste göras en hel del 
antaganden som ska förankras. Och just dessa subjektiva nyttor kan vara svåra att få gehör för 
p.g.a. de inte direkt presenteras till personer som kan hela företagsverksamheten. Det behövs 
också en planering så att rätt data insamlas som exempelvis, antal gånger, antal kunder, löner, 
hur lång tid vissa saker tar etc. dessa data är kanske inte relevant för andra metoder, men 
viktiga för denna. 

Vilka problem och styrkor finns med att kombinera dessa fyra metoder? 

Styrkor 

Den styrka som finns med att kombinera dessa fyra metoder, är att de har olika angreppssätt 
och täcker varandras brister. Genom att jämföra resultaten från respektive metod kändes 
resultatet mer trovärdigt. Metoderna med sina olika angreppssätt gör resultatet mer 
tillförlitligt i form av överensstämmelse, bristande överensstämmelse och motsägelse, allt för 
att säkerställa utvärdering. Min uppfattning är att jag i den givna situationen lyckades 
säkerställa de problem som respektive målgrupp upplevde, men även de fördelar som IT- 
systemet hade. 

Styrkan är just att metoderna har olika angreppssätt och på så vis utvärderar IT-systemets 
funktioner, gränssnitt och hur effektivt målgrupperna i systemet kan utföra sina 
arbetsuppgifter. Detta tycker jag bidrar till en mer heltäckande utvärdering. Att sedan använda 
metoden kostnad - nytta - analys för att presentera delar av de andra metodemas utvärderings 
resultat i form av positiva och negativa effekter för IT-systemet upplever jag bidrar med en 
annan syn för något vi många gånger bara tar för givet att ett nytt IT-system ska bidra med. 

Problem 

Att kombinera flera metoder tar sin tid och kan till en början upplevas som onödigt. Det kan 
även kännas frustrerande att hitta data som är viktiga men som inte passar in i den metod man 
för tillfället arbetar med. 
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10 Avslutande reflektioner 

Här redovisar jag mina reflektioner över hur det har varit att arbeta med utvärderingen och 
vad jag genom undersökningen kommit att bidra med. 

Detta är min andra utvärdering av ett IT-system och det som skiljer är metoder och att jag nu 
var ensam. Det var arbetsamt i vissa lägen då det inte fanns någon att diskutera med. Men så 
här efteråt ser jag det som en bra och lärorik period. Jag har haft nytta av att jag arbetat med 
vissa av metoderna förut och att jag har en ekonomibakgrund. Även Jayaratnas ramverk 
NIMS AD har varit till stort stöd, vilket givit mig ett annat perspektiv på hur metoder 
konstrueras och hur jag som utövare bör och kan granskas, för inga metoder, oavsett 
användningsområde eller innehåll, är felfria eller kompletta. Det finns alltid utrymme för 
förbättringar. Den erfarenhet jag nu fått av metoderna gör att för nästa eventuella utvärdering 
så ska den kriteriebaserade utvärderingen bytas ut mot någon mer användbar metod, helst en 
metod med användarmedverkan och inriktad på gränssnittet. 

Att planera för datainsamling för de fyra metoderna på en och samma gång var mödosamt 
p.g.a. att tiden var så kort. Jag kände först en oro att jag hade glömt någon information men 
det fungerade förvånansvärt bra. Att sedan arbeta efter Jayaratnas ramverk NIMS AD var till 
stort stöd. 

Det ska tilläggas att jag under skrivandet av denna uppsats har läst ett flertal kurser i MDI 
vilket kan ställa till problem i form av ny kunskap och tidsåtgång. Jag ser det ändå som en stor 
fördel, med att ha fått djupare förståelse för människors kognitiva processer, användartester, 
kooperativ design och prototypanvändning i systemutvecklingsprocessen. 

Den erfarenhet jag har fått under denna utvärdering ger mig ännu fler argument för att 
införandet av ett IT-system måste föregås av en ordentlig verksamhetsanalys, 
målgruppsanalys och vilka effekter som ska uppnås med IT-systemet. Jag upplever en 
kunskapsbrist med avseende på vad användbarhet är från både beställare och leverantör. Den 
uppfattning jag har fått när jag diskuterat denna fråga är att det misstolkas och ses som något 
som kostar och tar tid, men det är ju faktiskt raka motsatsen. Därför tror jag att det behövs 
mer kon kr eta exempel som kostnad - nytto - analyser som visar att omständliga IT-system 
kostar i produktionen och att dessa kostnader är dolda och inte syns. Många gånger har jag 
mötts av användare och utvecklare som tar för givet att det ska ta lång tid att lära sig hur ett 
system fungerar Det finns dock användare som till en början protesterar men vinner inget 
gehör utan accepterar till slut situationen och finner andra utvägar att lösa arbetsuppgiften. 

Min förhoppning är, att dessa metoder ska ses som ett möjligt sätt att utvärdera på. Jag hoppas 
även att användbarhetskrav ska få en mer framträdande roll i kravspecifikationer. Min 
förhoppning är givetvis att både återförsäljare och leverantör ska se resultatet som positivt, för 
genom att belysa både de starka och svaga sidorna finns det möjlighet till förbättringar och att 
utvecklingen görs utifrån fakta. 
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Här redovisas en sammanfattning av de intervjuerna jag gjorde med respektive 
respondent. Därefter har jag valt att lägga den kriteriebaserade utvärdering som 
gjordes med respektive respondent. Mina bedömningsgrunder för den kriteriebaserade 
utvärderingen är följande, eftersom det inte finns någon given ram för hur det är tänkt 
att dokumentera utvärderingens resultat har jag valt följande sätt: 

Uppfyllt = Då anser jag att kriteriet är uppfyllt, alltså inga påpekande har framförts av 
respondenten eller något framkom under observation. 

Delvis uppfyllt = Då anser jag att det till hälften är uppfyllt, dvs. det finns antigen en eller två 
påpekanden på kriteriet. Endera så visade respondenten påpekandet eller så framkom det 
under utvärderingen av kriteriet. 

Ej uppfyllt = Då var kriteriet inte alls uppfyllt och var till stor betydelse för respondentens 
arbetsuppgifter. 


Ekonomiansvarig 

Det är viktigt att ha ett system som stödjer oss att ge våra kunder en bra service och det skulle 
det nya systemet bidra till ännu mer. Det är viktigt att vi i ledningsgruppen kan få ut snabb 
och tillförlitlig informationen så vi kan styra verksamheten. Det är också viktigt att vi kan ge 
våra kunder en snabb och riktigt information. 

Inom vår bransch har vi som tradition en stark mur mellan olika funktioner, men vi hoppas nu 
att vi ska kunna arbeta bort den. Vi har som mål med det nya systemet att få bort mycket av 
den administrativa del och kunna jobba mer direkt mot kunden för att ge ännu bättre service. 
Respondenten har tittat mycket på den interna hantering emellan funktionerna (processerna) 
och sett att det kostar oerhört mycket när det blir fel i mellan dessa och till slut är kunden som 
drabbas. För respondentens del kom implementeringen vid samma tidpunkt som årsbokslutet 
och de upptog då mycket tid för respondenten. Så med facit i hand så borde vi ha varit mer 
aktiva och kritiska för då hade vi kunnat ha undgått ett flertal negativa effekter som vi nu får 
sitta och brottas med. 

Personalen träffas varannan månad och får information om företagets resultat och andra 
viktigt information som bl.a. affärsidé och strategier. Företagets vision är att behandla alla 
kunder lika. Ett stort problem man har är att ta hand om kunder som ringer till 
kundmottagningen runt klockan 16.00-17.00 och vill höra om bilen är klar. Vi har nu så det 
går att boka tider direkt via webben och ser det som ett sätt att öka tillgängligheten för 
kunderna. Vi har även börja se om det går att dela upp kort-, kontant och kunder som bara ska 
hämta sin bil. Allt detta för att ge bättre och snabbare service. De har även fört diskussioner 
om möjligheten till att introducera processbaserat arbetssätt. 


Arbetsbeskrivning 

Har det övergripande ekonomiska ansvaret för företaget samt håller i övergripande 
personalfrågor. 

Information för att för att göra månadsbokslut och olika typer veckorapporter så som lager, 
leveranser, och utfall mot budget hämtas från IT-system X till ekonomisystemet. 
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Positivt 

• Det går mycket enklare och snabbar att hämta information från IT-system X nu än från det 
gamla systemet. 

• Det finns en rapport som nu visar försäljningsstatiskt och den är väldigt bra och lätt att ta 
fram. 

• Det är positivt med alla förhandsgranskaningar som kan göra på olika listor, nu har även 
VD fått lära sig att kunna gå in och kontrollera vissa försäljningsrapporter, så han tryggt 
kan åka hem och vet att allt fungerar. 

Negativt 

• Det finns ingen bra rapport som fångar upp försäljningen från servicemarkanden 
framtagen ännu, men det ligger under prioriterade ärenden. 

• Det man saknar är en direktkoppling mellan systemen (IT-system X och 
bokföringssystemet) nu har inte batchkörningen fungerat (ska köras varje natt, är tänkt så) 
utan man fått plocka siffror manuellt mellan systemen. 

• Vid selektering av information till en rapport kan man göra vissa urval, (en formulärbild 
kommer upp med att visa given urval som man kan välja emellan) men för att kunna ändra 
måste man gå in under detaljerat och där välja t.ex. fakturerat, men först måste man ha 
avmarkerat i kryssrutan ”totalt”, för att kunna ändra vilket alternativ man vill ha. När man 
sedan har gjort alla val, då måste man igen markera kryssrutan ”totalt”. När denna 
funktion skulle visas på en konferens var respondenten tvungen att visa de ”lilla knepet” 
för representanten för systemet X, så att de kunna visa för andra närvarande hur det 
fungera. 


Upplevda brister hos systemet 

• Att integrationen mellan bokningssystemet och system X inte fungerar som tänkt 
(implementerades för ett år sedan). Moderbolaget som godkände Systemleverantören X 
hade inga krav uppsatta på att integrationen skulle fungera, utan deras krav var främst 
inriktade på integrationen mellan Systemet X och fabriken. Alltså finns ingen 
funktionskontroll mot applikationen.) Detta är ett problem när det ska integreras i fler 
länder i Europa och man har olika uppfattningar om vad som ska prioriteras. Men man har 
från Moderbolagets sida försökt att minska de olika affärssystemen från 25 till 5-6 
stycken totalt i Europa. 

• Vid implementationen uppmärksammade vi hur dåligt funktionen på var på denna del av 
systemet och stoppade då betalningsflödet för att få det åtgärdat. Först då förstod 
Systemleverantören X hur allvarligt problemet var, och nu är nästa allt är åtgärdat. Vi ger 
Systemleverantören X en eloge för sitt handlande och tycker man har blivit lystnad på och 
fått igenom sina påpekanden på ett bra sätt. Vi har nu infört månadsmöte med inblandade 
parter (återförsäljarna) där man kan stämma av och diskutera olika problem och 
påpekanden gällande System X. 

• I det gamla systemet så buntade man ihop alla fakturor för en den dag från t.ex. verkstad 
och körde över som en post. Det kan man inte göra nu utan för buntning i System X 
innebär att varje verifikat, enskild faktura förs över för sig, vilket innebär att den 
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transaktionen nu tar längre tid (ca 1 timme) varje dag. Nu skapas en 
bokföringstransaktionen för varje faktura vilket innebär att en bilaffär som i regel har en 
till tre betalar, då skapas de tre olika bokföringstransaktioner (konteringar) som är svåra 
att följa. Det var bättre i det gamla systemet där en bilaffär blev en bokföringstransaktion 
(kontering). Man ser inget värde i att dessa har delats upp, utan snarare ett problem om 
något blir fel och man ska följa alla dessa transaktioner. Man säljer ju en bil och då är det 
intressant att granska just den konteringen. 

• Kunna skapa egna rapporter. Det finns en rapportgenerator men den är väldigt komplex så 
den vill man inte ge sig in i. Fältnamnen är en blandning av flera språk så man vet inte om 
man valt rätt. Nu går Systemleverantören X ut och säljer olika rapportvyer som är skapade 
Crystal Reports men det vill man inte betala för. 

• Vissa nedskrivningar som ska göras på demonstrationsbilar med x antal kr (detta görs i en 
särskild modul). När man sedan ska flytta bilen till en annan modul, då kommer ett förslag 
på värde upp på bilen, värdet ska vara bokfört värde, men det stämmer inte vilket ställer 
till stora problem. Detta måste göras manuellt tills felet är åtgärdat. 
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KRITERIEBASERAD UTVÄRDERING MED EKONOMIANSVARIG 

Kriterium 

B edömningsgrund 

Kommentarer 

1. Enkelt kan förstås vad 
som kan göras med 
systemet (tydlig 
handlingsrepertoar) 

Uppfyllt 

Det upplever ekonomiansvarige att man 
gör 

2. Kan ”sägas” det man vill 

Ej 

Att integrationen ska fungera som tänk. 

genom systemet (tillgodose 
kommunikationsbehov) 

uppfyllt 

Kunna skapa egna rapporter. Det finns en 
rapportgenerator men den är väldigt 
komplex så den vill man inte ge sig in i. 
Fältnamnen är en blandning av flera 
språk så man vet inte om man valt rätt. 

Den finns igen översättingen på svenska 
och ingen bra handbok heller. 

3. Enkelt kan ta sig till 
önskad plats i systemet 
(lättnavigerbar) 

Uppfyllt 

Det tycker ekonomiansvarige är lätt och 
förståligt. 

4. Förstå konsekvenserna 
av föreslagna och utförda 
handlingar 

(handlingstransparent) 

Uppfyllt 

Det upplever ekonomiansvarige att det 
gör och det kommer upp meddelanden. 

5. Direkt se att det man 

Delvis 

Man kan inte lita på förslaget bokfört 

försökt göra blev gjort 
(feedback) 

uppfyllt 

värde som kommer upp i samband, när en 
bil ska flyttas till en annan modul. 

6. Enkelt få hjälp att veta 
vad som gjorts (tydligt och 
lättåtkomligt 
handlinsminne) 

Uppfyllt 

Det upplever ekonomiansvarige att det är 
genom att på historik. 

7. Vet vem som ”sagt” vad 
(personifiering) 

Uppfyllt 

Det går att se vem som har varit 
inloggad. 

8. Förstå använda begrepp 
(känd och begriplig 
vokabulär) 

Delvis 

Vissa ord kan missuppfattas i när man 
ska skriva ut vissa rapporter 
(försäljningsstatistik) t.ex. står det lager 
istället för orderstock. 

9. Förstå kommunikativt 
avsikt med olika 
meddelanden 

Delvis 

Det tycker ekonomiansvarige att man 
gör. Förutom att man inte lita på förslaget 
bokfört värde som kommer upp i 
samband, när en bil ska flyttas till en 
annan modul. 

10. Få ett bra stöd för 
handlande i verksamheten 

Delvis uppfyllt 

När alla fel är åtgärdade. 

Vissa nedskrivningar som ska göras på 
demonstrationsbilar med x antal kr (detta 
gör I en särskild modul). När man sedan 
ska flytta bilen till en annan modul, då 
ska ett förslag på värde av bilen komma 


4 




Bilaga 1 


upp och värdet ska vara bokfört värde, 
men det stämmer inte vilket ställer till 
stora problem 

De tre första månaderna kunde vi inte lita 
på siffrorna som kom ut från systemet. 


Lageransvarig 

Arbetsbeskrivning 

Respondenten har ansvar för lagerhållning, inköp och uppläggning av nya artiklar. Inköpen 

sker via inloggning mot andra system och via telefon, men ordern skrivs i system. 

Respondenten ansvarar för faktureringen mot företagskunder som köper reservdelar. 

Positivt 

• Respondenten anser att systemet stödjer hans arbetsuppgifter och många förbättringar har 
gjorts som att sökmomentet har blivit flexiblare, t.ex. att söka på kundnamn, vilket inte 
gick tidigare. Det har också blivit enklare och snabbare att ta ut information som till 
exempel att sammanställa en stor artikelfråga. Antigen man vill se informationen på 
skärmen eller skriva ut den. 

• Det finns ett stort antal rapporter man kan ta ut, men man ser inget behov av allt detta just 
nu i alla fall. Sökmoment på artikelnummer och leverantörer är bra. 


Negativt 

• De som har ställt till problem är, när en ny artikel ska läggas upp får man välja om den ska 
vara ” lagerförd artikel eller inte". "Lagerförd artikel” för respondentema betyder att 
artikeln ska tas hem för att ligga på hyllan. Men för system betyder ”lagerförd artikel” att 
artikeln tas hem, men ska inte lagerföras , utan säljas direkt. Detta ställde till stora problem 
i början när man sålde en artikel som inte fanns hemma, och fick upp frågan om den 
skulle lagerföras eller inte och naturligtvis svarade alla nej, eftersom artikeln skulle säljas 
direkt. Och inte skulle ligga på hyllan. Detta är påpekat för alla i företaget så man nu är 
medveten om de olika tolkningarna. 

• Rabattkoden för respektive artikel får inte plats i sin ruta (fast bara % är fylld), vilket 
innebär att man inte ser de sista siffrorna. Detta har resulterat i att man fått lagt hela 
rabattkoden i en inforuta, som kan tas fram för respektive artikel. Man vet inte varför hela 
rabattkoden inte får plats. Detta skapade problem i början för den sista siffran angav 
vilken rabatt företagskunderna hade. Detta innebar att man fick ändra hela sitt 
rabattsystem för företagskunder. 


Upplevda brister på systemet 

• Respondent känner inte att den jobbar effektivare genom bl.a. att det inte har blivit 
effektivare att fakturera. Genom att det inte går snabbare att lägga till det som ska 
faktureras på fakturan. Respondenten skriver ca 500 fakturor per månad. Att ställa 
prisfrågor till systemet har inte heller effektiviseras. Respondenten menar att hade man 
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bättre kunskap om målgrupperna hur dessa arbetar så hade man nog fått upp en bättre 
effektivitet på de viktigaste momenten. 

• Ett annat saknad behov är att kunna bläddra mellan sökta artiklar. 

• Att orientera sig i systemet är sådär, det är mycket klickande, men till slut har man 
accepterar allt klickande. 


KRITERIEBASERAD UTVÄRDERING MED LAGERANSVARIG 

Kriterium 

Bedömningsgrund 

Kommentarer 

1. Enkelt kan förstås vad som 
kan göras med systemet 
(tydlig handlingsrepertoar) 

Uppfyllt 

Det är lättare nu med ett 
Windowsbaserat system. Det går bra 
att ”klicka runt” och kolla. 

2. Kan ”sägas” det man vill 
genom systemet (tillgodose 
kommunikationsbehov ) 

Uppfyllt 

Det upplever lageransvarige att man 
kan. 

3. Enkelt kan ta sig till önskad 
plats i systemet 
(lättnavigerbar) 

Delvis 

Uppfyllt 

Lageransvarige upplever att det är 
mycket klickande för att komma dit 
man vill. 

4. Förstå konsekvenserna av 
föreslagna och utförda 
handlingar 

(handlingstransparent) 

Uppfyllt 

Det upplever lageransvarige att man 
får bra meddelande om vad görs eller 
inte. 

5. Direkt se att det man 
försökt göra blev gjort 
(feedback) 

Uppfyllt 

Det upplever lageransvarige att han 
får. 

6. Enkelt få hjälp att veta vad 
som gjorts (tydligt och 
lättåtkomligt handlinsminne) 

Uppfyllt 

Det upplever lageransvarige att det är 
genom till exempel historiken. 

7. Veta vem som ”sagt” vad 
(personifiering) 

Uppfyllt 

Det inloggade namnet dokumenteras. 

8. Förstå använda begrepp 
(känd och begriplig 
vokabulär) 

Delvis 

uppfyllt 

Lagerförd artikel betyder för 
återförsäljarna, att den tas hem för att 
ligga på hyllan. Systemet menar 
tvärtom. 

9. Förstå kommunikativt 
avsikt med olika meddelanden 

Delvis 

uppfyllt 

Ett problem är om en artikel sälj och 
inte finns hemma kommer en 
dialogruta upp och frågar om varan ska 
lagerföras. Nu vet alla att detta 
meddelande betyder ”vill du sälja 
artikel fast den inte finns hemma”. 

10. Få ett bra stöd för 
handlande i verksamheten 

Delvis 

uppfyllt 

Ser inte hela rabattkoden i 
artikelformuläret. 

Prisfråga till kunden 
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Servicemarknadsansvarig 

Arbetsbeskrivning 

Den huvudsakliga arbetsuppgiften ska vara servicemarknadsansvarig, men fick som första 
uppgift att vara stöd under implementeringen av det nya systemet. Arbetet består av 
uppföljningar av försäljningar inom verkstad och reservdel. Systemunderhåll ingår också som 
t.ex. uppläggning av nya kunder i systemet. Fixar också de problem som tidstämplingen kan 
orsaka som om mekaniker glömmer stämpla in eller ut. Verkstadsmodulen har en 
tidsredovisningsdelen vilket innebär att en mekaniker måste ha varit instämplat på en faktura 
för att den ska kunna faktureras. Det är också ett krav från generalagenten för att få betalt för 
reklamationer. 

Verkar också som Super Users/Expert och hjälper till om någon inte kommer ihåg hur vissa 
moment skall göras i systemet. Är den som samlar in krav, behov och fel till 
systemleverantören. 


Positivt 

• Alla Rapporter som har tillkommit och att man nu kan förhandsgranska en faktura innan 
den faktureras. Det finn nu en rapport som visar ”ej fakturerat” och kan skrivas ut 
per/användare, vilket inte gick i det gamla systemet, där fick man bara ut en enda lång 
lista på alla. Nu är det mycket enklare att ta ut viktig information förutsatt att alla i 
systemet sköter sin del och stämplar in/ut. 

• Det finns en tilläggsmodul i systemet som lätts köras för att se om hur långt man kommit 
med arbetsordem (när en kund ringer och frågar). Den visar statusen på en arbetsorder, 
t.ex. om den är färdig och fakturerad eller färdig men inte fakturerad, eller om man väntar 
på delar. Denna finess försöker respondenten nu marknadsför in bland personalen. Men 
man är ganska konservativ i sin syn på det egna arbetet trots att man håller på med 
avancerad teknik. 

Negativt 

• Genvägar till rapporter är konstigt döpta, vilket innebär att genvägen inte har samma 
namn som rapporten. Verksamhets språket är inte riktigt konsekvent t ex benämning 
”Främmande arbete” och ”underleverantör” det blir diskussioner om vad som är vad. 


Upplevda brister hos systemet 

• Prisuppgift till kunden är inte enkel att få fram (skyldig att lämna till kunden enligt 
konsumentköplagen). Den prisuppgift som kommer upp på skärmen går inte att skriva ut 
direkt, samt att den inte bara visar den summan som kunden ska betala utan hela den totala 
kostnaden för hela arbetsordern. Man får alltså göra ett flertal extra moment för att få bort 
de andra summorna. Det går att skriva ner summan till kunden på en vanlig lapp, men att 
få ut en prisuppgift skulle underlätta vid uthämtningen. Då skulle kunden visa upp den vid 
uthämtningen och det skulle då vara säkrare att det verkligen är kundens bil. 

• För att kunna stjäla en modern bil i dag så måste man ha bilnyckeln. Nu kan vem som 
helst komma in och ange ett bilnummer och hämta bilen genom att betala 3 000 kr. Det 
system man nu har med nyckeltaggar, så begärs ingen legitimationen vid uthämtningen 
legitimation utan frågar efter namnet och jämför sedan namnet det mot ordern och 
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nyckeltaggen. Ett prisuppgiftskvitto skulle motverka visa försök till stöld genom att 
kunden visade upp detta vi avhämtning. 

• Det skulle vilja att när man tar ut arbetsordem så fick man frågan om man vill ha 
prisuppgift till kunden automatiskt. 


KRITERIEBASERAD UTVÄRDERING MED 
SERVICEMARKNADSANSVARIG 

Kriterium 

Bedömningsgrund 

Kommentarer 

1. Enkelt kan förstås vad som 
kan göras med systemet (tydlig 
handlingsrepertoar) 

Uppfyllt 

Det upplever 

servicemarkandsansvarige det är med 
det Windows baserade än med det 
textbaserade systemet. 

2. Kan ”sägas” det man vill 
genom systemet (tillgodose 
kommunikationsbehov) 

Uppfyllt 

Det upplever 

servicemarkandsansvarige att man 
kan. 

3. Enkelt kan ta sig till önskad 
plats i systemet 
(lättnavigerbar) 

Uppfyllt 

Det upplever 

servicemarkandsansvarige att man kan 
göra. Det är lätt att klicka blev man 
ska. 

4. Förstå konsekvenserna av 
föreslagna och utförda 
handlingar 

(handlingstransparent) 

Uppfyllt 

Det upplever 

servicemarkandsansvarige man gör . 
Medlandena är tydliga. 

5. Direkt se att det man försökt 
göra blev gjort (feedback) 

Uppfyllt 

Det upplever 

servicemarkandsansvarige man får. 

T.ex. tas något bort så bekräftas det. 

6. Enkelt få hjälp att veta vad 
som gjorts (tydligt och 
lättåtkomligt handlinsminne) 

Uppfyllt 

Det upplever 

servicemarkandsansvarige man lätta 
kan komma åt historiken. 

7. Vet vem som ”sagt” vad 
(personifiering) 

Uppfyllt 

Det inloggade namnet dokumenteras. 

8. Förstå använda begrepp 
(känd och begriplig vokabulär) 

Ej 

uppfyllt 

Problem med begrepp som 
”främmande arbeten” och 
”underleverantör” återförsäljarna har 
olika tolkningar om vad som är vad. 
Genvägarna till rapporterna 

9. Förstå kommunikativt avsikt 
med olika meddelanden 

Uppfyllt 

Det upplever 

servicemarkandsansvarige att det gör. 

10. Få ett bra stöd för 
handlande i verksamheten 

Delvis 

Uppfyllt 

Nej, att ge prisfråga till kunden är 
komplicerat och medför många 
moment. 
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Kundmottagare 

Arbetsbeskrivning 

Tar emot kunder direkt vid disken(c:a 30 - 40 st per/dag) eller via telefon gällande 
prisuppgifter, tidsbeställning, akuta problem eller utlämning av färdigservade bilar. Skriver ut 
arbetsorderna, fakturerar och kontrollerar fakturor från verkstad. Vid specifika fall där kontakt 
med kunden måste göras för att rådfrågning tar de även denna kontakt. 

Tidsbeställning görs i Excel fil. Vid servicetidsbokning kontrolleras om reservdelar måste tas 
hem om det behovs går man direkt efter utskriven arbetsorder till lageransvarig som då ska 
ansvara för att reservdelen finns hemma tills servicetiden. 

De hämtar färdiga fakturor i en korg inne hos verkmästarna. De går sedan igenom och 
kontrollerar rabatter samt ringer upp kunden och säger att allt är klart och det kostar så 
mycket. Men nu tar det så lång tid att få fram fakturorna så kundmottagarna hinner knappt 
kolla igenom alla fakturor ordentligt så de stämmer innan, utan i regel är det kunden som 
upptäcker fel. Det kan också vara så att när kunden kommer och ska betala, så har den med 
sig en rabattkupong. Kundmottagarna får då gör en kreditfaktura och sedan lägga i rabatten 
som är missad. 

När kunderna ringer och frågar om deras bil är klar så finns tilläggsmodul i systemet som lätts 
köras för att se om hur långt man kommit med arbetsordern. Den visar statusen på en 
arbetsorder, t.ex. om den är färdig/fakturerad eller färdig men inte fakturerad om man väntar 
på delar. 

Det finns tre kundmottagare på företaget. 

Positivt 

• Att skapa servicepaket har blivit enklare. Alla delar som man läggs till går på 
chassinumret så det ska stämma mot respektive bil. Paketet visar vad det är för material, 
arbete, objektkod och kostnaden. 

• Att ta del av historiken krävs bara en knapptryckning. 

• Det är enkelt att ta bort från arbetsordern, bara markera vilken rad det gäller och den 
radens får ett kryss framför, vilket innebär att den inte sparas. Rader som inte är sparade 
visar en pil framför. Det är viktigt att spara innan man skriver ut, för det är bara det som är 
sparat som skrivs ut. Respondenterna spara ideligen för det är vanligt att systemet låser sig 
och då tappar man information vilket är negativt. 

• Enklare gör kreditfakturor. 


Negativt 

• Att lämna prisuppgift till kunden är omständligt. Det är i regel flera betalningsinstanser på 
en service, t.ex. finns det garantier som ska stå för visa utav kostnaderna. På arbetsordern 
är allt noga specificerat, så för att skriva vad kunden faktiskt ska betala ut så plockar man 
bort de kostnaderna som andra ska betala genom att ange delkostnad och sedan skriva vad 
som avgår. Dessa kostnader förs sedan över till ett tillfälligt internt konto och då till slut 
ska bara kundens kostnad visas. 
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I det gamla systemet som var från 1970-talet fungerade det på samma sätt, men inte i det 
nya system, det visar fortfarande det totala priset. Vilket medför stor förvirring för kunden 
och de anställda. Nu har man vant sig och tagit till strategin att göra som ovan med lägg 
till en rad där det står: ” uppgivet pris xxxx” till kunden. Eftersom som det inte är lätt att 
avläsa på en arbetsorder vad kunden ska betala. Och för en anställd som hoppar in 
tillfälligt ställer detta till stora problem. Man har insätt faran med att ständigt informera 
muntligt till kunden och försöker nu att skriva på varje arbetsorder vilket pris som har 
uppgivits. 

• Om man måste ändra kunduppgifter på en arbetsorder. Kan man antigen då gå in under 
kund och sedan ändra betalare, men det gäller bara för denna arbetsorder. Vill man ändra 
uppgifter permanent måste man ändra i kundregistret och vägen är inte helt solklar: Gå in 
under Fordon, Fordonsdata, Funktion, Gränssnitt och SBR. Man sparar sedan alla uppgifter 
och får frågan om det ska uppdatera, man svara jag och får bekräftat att kunden är 
uppdaterad. Men arbetsordern är inte uppdaterad, utan man måste ändå gå in under kund 
och ändra betalare. De nya uppgifterna kommer inte in förrän en helt ny arbetsorder tas 
fram. Detta skapar frustration eftersom man uppdaterar via bilregistret men ända måste 
man ändra manuellt. Att alla kunduppgifter stämmer är viktigt eftersom de senare ligger 
som underlag för fakturan. 

• Det kan också vara så att man bara har fordonets uppgifter på arbetsordern och ska sedan 
hämta ägareuppgifter till arbetsorder är det samma problem arbetsordern uppdateras inte, 
utan man får lägga till det manuellt. Men det märkliga är att om man ändrar t.ex 
telefonnumret och sedan sparar och uppdaterar, då kommer det nya uppgifterna med. OBS 
vid alla tillfällen får man en fråga från systemet, om det ska uppdateras. Detta är 
frustrerande och man också kunden framför sig som står och väntar och måste igenom alla 
dessa moment känns det stressande. 

• För att söka efter arbetsoperationer måste man vara väl insatt i olika nummerföljder. Det 
anges inte om man ska på bokstäver eller nummer. T ex ska man ange ”Byta bälten” eller 
”35”. Man kan inte bara öppna och bläddra mellan posterna, utan man måste ha koll de 
olika numren för de olika objekten. Det finns även två andra sökvägar att ta till och då 
söker man på kampanjer eller vanliga jobb, och skulle man här hitta det man söker så kan 
man skicka dessa arbetsoperationer till det till sin arbetsorder som helt plötsligt bytt namn 
till "DMS”. 


• Respondenten menar att det saknas väldigt mycket arbetsoperationer som man skulle vilja 
kunna välja mellan. Vilket innebär att kundmottagaren får skriva egna textrader som då 
saknar objektkoder. Här känns det som det saknas kunskaper ifrån utvecklama. 

• Att man nu inte kan spara arbetsordnama i system utan måste skriva ut dem direkt, även 
om det är ett halvår i förväg och medfört en stor försämring. Arbetsordnama skrivs nu ut 
och lagras i en låda sorterade på datum mellan kundmottagarna. Dessa sätts sedan upp på 
en tavla som rymmer två veckors planering för verkstan. I lådan kan det ligga arbetsorder 
för ca åtta månader framåt. Man har haft problem med att arbetsorder kommit bort, visst 
kan man skriva ut dem igen, men det har uppstått en annan risk med detta. Om då ett 
tillägg har gjorts på den utskrivna kommer det att vara borta på den ny utskrivna 
arbetsordern. 
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Upplevda brister hos systemet 

• Att arbetsordema ska ligga kvar i systemet, för att sedan kunna skriva ut dessa efter 
datum. 

• Enklare att uppge prisuppgifter till kunden och tydligare förklaring vem som ska betala 
vad så det inte kan bli missar. 

• Enklare att söka bland på arbetsoperationer. 

• Att kunna uppdatera kunduppgifter på arbetsordern utan att ändra förhand eller kassera 
och ta fram en ny arbetsorder för att uppdateringen ska fungera. 


KRITERIEBASERAD UTVÄRDERING MED KUNDMOTTAGARE 

Kriterium 

Bedömningsgrund 

Kommentarer 

1. Enkelt kan förstås vad 
som kan göras med 
systemet (tydlig 
handlingsrepertoar) 

Ej 

Uppfyllt 

Exempel: Det är inte lätt att se hur man får 
fram en ny arbetsorder. Efter man är 
färdigt men en arbetsorder, ligger den 
fortfarande kvar på skärmen. Man får inte 
heller någon info om att den föregående är 
sparad. 

Önskemål är att när en arbetsorder är klar 
ska den försvinna från skärmen och en ny 
komma fram. 



Det finns en listruta på arbetsordern där 
man kan välja språk. Ingen vet vad den ska 
användas till. Respondenten testade att 
välja ett annat språk, men inget hände. Det 
finns även en listruta med kontogrupper 
som inte hör till kundmottagningen. Alltså 
finns det funktioner på skärmen som inte 
hör till kundmottagningen. 



Det finns knepiga 

verktygsknappsmetaforer som inte direkt 
associerar till Office/Windows miljön eller 
till verksamheten/målgrupper. T.ex. en 
knapp med en gris ska associera att man 
makulerar en rad. För att markera en rad 
finns metaforen mutter verktygsknappen. 

2. Kan ”sägas” det man 
vill genom systemet 
(tillgodose 

kommunikationsbehov) 

Ej 

Uppfyllt 

Uppge pris till kunden och så andra i 
verksamheten skall se vilket pris man 
uppgivit till kunden 

3. Enkelt kan ta sig till 
önskad plats i systemet 
(lättnavigerbar) 

Delvis 

uppfyllt 

Ja, om man håller på med systemet 
dagligen. Menyerna är inte helt 
associerade med vad man ska göra. 

Exempel ändra kunduppgifter 

4. Förstå konsekvenserna 
av föreslagna och utförda 

Delvis 

uppfyllt 

Vissa uppdateringar uppdateras inte trots 
meddelande från systemet att det är gjort. 
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handlingar 

(handlingstransparent ) 



5. Direkt se att det man 
försökt göra blev gjort 
(feedback) 

Delvis 

uppfyllt 

Ja/nej, se ovan. 

6. Enkelt få hjälp att veta 
vad som gjorts (tydligt och 
lättåtkomligt 
handlinsminne) 

Uppfyllt 

Historiken är lätt och smidig att ta fram. 

7. Vet vem som ”sagt” vad 
(personifiering) 

Uppfyllt 

Det inloggade namnet dokumenteras. Och 
det är även lätt att ändra. 

8. Förstå använda begrepp 
(känd och begriplig 
vokabulär) 

Uppfyllt 

Vissa knappar har konstiga metaforer. 
Samtidigt är det svårt att lägg upp 
arbetsoperationer om man inte har mycket 
erfarenhet, för det är inte givet hur man 
söker eller får tillgång till hela listan. Det 
står inte om man ska söka på 
siffror/bokstäver. Det finns sök ord, men 
då måste man kunna kombinera dessa rätt. 

o 

Man MASTE ha Mycket kunskap som inte 
finns i systemet. 

Måste ha en stor kunskap och vara väl 
insatt för att söka bland arbetsoperationer. 

9. Förstå kommunikativt 
avsikt med olika 
meddelanden 

Delvis 

Uppfyllt 

Systemet talar om att kund info är 
uppdaterat, men talar inte om att det gäller 
när en ny arbetsorder skapas, alltså inte på 
den befintliga som man arbetar med, vilket 
förutsätter. 

10. Få ett bra stöd för 
handlande i verksamheten 

Ej uppfyllt 

Nej, att ge prisfråga till kunden är 
komplicerat och medför många moment. 

Det är krångligt att ändra och hämta 
kunduppgifter. 
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Egen mekaniker 

Arbetsbeskrivning 

Mekanikern gör allt själv vilket innebär kundmottagning, tidsbokning, service och fakturering 
till kund. 

Positivt 

• Det är mycket enkelt att göra kreditfrakturer och de uppskattas verkligen för det var 
krångligt i det gamla systemet. 


Negativt 

• Tidsstämpling är bra när det är stora jobb men ska man bara byta en glödlampa på en bil 
blir massor av jobb på en faktura, eftersom allt måste fyllas i på en arbetsorder för att 
sedan få ut en faktura. Vilket innebär att små jobb som t.ex. byta en glödlampa tar längre 
tid att administrera en för en mekaniker att utföra jobbet. 

• Kunder som är anställda hos viss bilmärken eller ägare till ett märke har olika rabatter 
inlagd i kundregistret. Beroende var man står när man hämtar in dessa kunduppgifter så 
kommer rabatten med ibland och ibland inte. Detta medför att rabatt kommer på vissa 
artiklar med läggs det till några så kommer inte det med på dessa. Är det då ett stort jobb 
och kunden har bortåt 30 poster med olika rabatter som ska läggas till manuellt så tar detta 
en himla tid att fördela de olika rabatterna på respektive post. Därför vore det smidigare 
att det inte fanns någon rabatt alls inlagd, utan den lades till sist på fakturan. 

• Ett problem är att när man skapar en ny arbetsorder och anger den nya mätare 
inställningen så kommer den gamla upp i alla fall. Samtidigt så har datumet som kommer 
in automatiks daterat 1899-01-01 så det gäller att inte vara trött och glömmer att ändra. 

• Mekaniker menar att han har sänkte sin årslön med 20 000 kr p.g.a. av att det tar så lång 
tid att fakturera i det nya systemet. Han har lika mycket jobb nu som förr men han får 
jobba över både på lunchen och på kvällarna för att hinna med. Mekanikern känner att han 
fakturerar 75 % och mekar 25 % av sin tid på verkstan. 

• Ett annat problem är när man ska plocka in arbetsoperationer till arbetsordern och är 
stressad då är det lätt att man väljer fel knapp ”Ny” istället för ”Välj” man väljer 
operationer för att sedan plocka över dem. Dessa ligger nära varandra, och skulle man 
råka tycka på ”Ny” (skapar en ny arbetsoperation), då börjar systemet stå och tugga 
(särskilt om klockan är 15.45 då är systemet extra segt) och när den väl har tuggat klar så 
frågar den efter en operationskod, och det är det svårt att avbryta kommandot och komma 
tillbaka till det ursprungliga lägget, vanligtvis är att man får stänga ner hela och börja om 
från början. 


Upplevda brister hos systemet 

• Det tar alldeles för lång tid att fakturera 


13 



Bilaga 1 


Verkmästarna 


Arbetsbeskrivning 

De har ansvar för verkstad och arbetsfördelningen för mekanikerna, vilket innebär att se till 
att arbetsorderna kommer till rätt mekaniker med rätt kompetens som fodras. Vidare har de 
ansvar för kontakter med kunder om något tillkommer under arbetets gång t.ex. om något mer 
upptäcks som måste åtgärdas. Stöttar och hjälper mekanikerna om de har funderingar om 
något på en arbetsorder. Kan även lägga upp arbetsorder om det skulle behovs. Hjälper/och 
ev. tar över från kundmottagningen om det gäller tekniska problem som kunden vill diskutera. 

Mekanikerna hämtar och lämnar sina respektive arbetsorder i korgar inne hos verkmästarna, 
som går igen dessa färdiga arbetsorder och kollar så att prisuppgifter och rabatter stämmer 
med vad som är överenskommet och vad som gjorts. Det kan skilja en del och ganska ofta står 
det på arbetsordem att ”ring om pris” menar respondenten. Detta kan ofta röra felsökningen 
och respondenterna menar att man i kundmottagningen skulle kunna uppge ett prisförslag. De 
ansvarar också för att det som är tillagt på förhand förs in på fakturan. 

Nu måste man varje eftermiddag stänga in sig för att sitta och redigera frakturer det går inte 
att göra så mycket i förväg. När man är klar med en faktura skrivs den ut och läggs i en korg 
därifrån hämtar sedan kundmottagarna. 

Det som var meningen med det nya systemet var att verkmästarna skulle granska och lägga 
till på fakturan, för att sedan skicka vidare till kundmottagama som bara skulle behöva 
förhandsgranska och kolla av mot kunden att allt stämde för att sedan skriva ut faktura. Men 
det funkade inte på grund av att kundmottagarna inte kunde lägga in mekanikerns tids 
stämpling på fakturan. 

Positivt 

• Det är mycket enkelt att göra kreditfrakturer och de uppskattas verkligen för det var 
krångligt i det gamla systemet. 


Negativt 

• Att det inte fungerade som tänkt med faktureringen mellan kundmottagare och 
verkmästare (se arbetsbeskrivning ovan). Även om nu verkmästarna gör faktureringen. 

• Man ser bara att en mekaniker ha varit instämplad på en arbetsorder och inte förrän vid 
fakturering så upptäcker man att det har varit fler. 

• Rabatter ställer till en hel del problem i systemet. Rabatter kan inte kundmottagningen 
förbereda något av. Det är konstant 15 % rabatt, men skulle kunden lägga till något mer på 
fakturan så innefattas inte den artikeln. Det krockar också med andra rabatter som t.ex. en 
anställd för ett bilmärke har en viss rabatt på artiklar. Då måste man gå in på varje artikel 
och lägga till rabatten för hand. Har sedan kunden både service och garanti jobb utförda 
på arbetsorder och man klickar på att knappen lägg till rabatt då kommer den bara längst 
ner där det står garantijobb inte på det andra som det också är rabatt på. Detta gör att man 
lägger till alla rabatt förhand vilket tar tid med allt klickande och det är lätt att man missar 
någon post. 
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• Kunder som är anställda hos viss bilmärken eller ägare till ett märke har olika rabatter 
inlagd i kundregistret. Beroende var man står när man hämtar in dessa kunduppgifter så 
kommer rabatten med ibland och ibland inte. Man har fått förklaringen till att det är en 
win.ini fil som läses sönder och det är därför de blir så. (Är på gång att lösas). 

• Servicepaket som inte är uppdelade och som man måste sitta och flytta till intemkonto för 
att kunden inte ska stå för hela kostnaden. (Denna är samma procedur som 
kundmottagaren gör) 

• Det finns kortkommandon med det är svårt att komma igång och lära sig alla som behovs 
och verkmästarna börjar känna av allt klickande i musarmen. 

• Det tar tid att fixa så fakturorna ser bra ut. Verkmästarna försöker göra fakturorna så 
tydliga som möjligt som att dela upp poster och lägga till rader för att det ska bli 
överskådligt och begripet för kunden. Servicepakten kommer in på ett sätt (delarna först 
och sedan arbetet), ska man sedan lägga till egna jobb så kommer de in tvärtom och då 
måste man sitta och flytta om så det blir konsekvent. Ska man lägga till egna textrader så 
kommer texten in i små bokstäver och måste då ändras till versaler, samtidigt måste man 
kontroller att raden kommer i linje med de andra för hamnar lätt lite varstans annars. 

• Detta innebär att fakturorna kan se olika ut beroende på vem som har gjort den. Detta är 
nytt för i det gamla systemet var allt fast och man plockade in jobb för jobb, och det lades 
till utan att man behövde tänka på utseendet på fakturan. Där fanns det färdiga koder som 
man slog in för att lägga till "Din mekaniker har varit: Bo Ek” och man kunde efter 
säsonger lägg till olika meddelande till kunderna som kom inrammat snyggt och prydligt: 
Vi på xxxx önskar en God jul och Gott Nytt år, eller Glad påsk, eller Trevlig sommar. Nu 
måste man lägga till detta manuellt och det tar ju också sin tid tillsammans med det övriga 
redigeringsarbetet på fakturan. Denna fines saknar man mycket. 

• Ett stort problem är att när man har en in en arbetsorder där det bara ligger uppradat vilka 
reservdelar som mekanikerna har bytt. Den ska nu redigeras och delas upp så 
arbetskostnaden m.m. under respektive reservdel, då är det lätt att man tycker bort sig och 
råkar ta bort någon reservdel. Förut hängde raderna kvar så man såg skuggor av raderna 
och kunde hämta in dem igen, nu är de bort om man inte har sparat. Så det är oerhört lätt 
att tappa bort poster och man skulle vilja ha en knapp tryckning (ångra) tillbaka. Nu får 
man gå ut till lagret igen och spela dum (man vill ju inte avslöja att man tappat order 
raden). Det säjs att man ska kunna spåra det tappade men man har inte fått det att fungera. 
Det medför att det kan bli svin i lagret om man inte upptäcker att man tappat reservdelar. 

• Ett annat problem är om man ska ta över arbetsorder från varandra, då vem man inte om 
det andre har sparat eller inte, och skulle systemet då låsa sig (vilket är vanligt 
förekommande), ja då tappar man allt arbete som inte är sparade. 

• Ett annat problem är att när man skapar en ny arbetsorder och anger den nya mätare 
inställningen så kommer den gamla upp i alla fall. 
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Upplevda brister hos systemet 

• Verkmästarna ser inte på fakturan vem som har varit mekanikerna utan måste gå in i 
systemets historik för att hitta dessa uppgifter. Den tids stämplade mekaniker borde 
komma med på arbetsordem automatiskt, eftersom man inte kan fakturera utan att en 
mekaniker har varit instämplad på fakturan. 

• Om en kund ringer och vill veta vad en vis arbetsoperation skulle kosta och sedan vill 
beställa den operationen, då kan man inte föra över den arbetsoperationen till en 
arbetsorder. Man måste först ha skapat en arbetsorder för det ska funka. Vilket innebär att 
har kunden frågat om många operationer, så gäller det att komma ihåg dessa eftersom man 
måste börja om från början och öppna en ny arbetsorder för att sedan lägga till 
arbetsoperationerna. 

• Att kunna skrivas ut fakturor på ett annat språk. Det finns ett annat system som är 
integrerat med detta system som klara flera olika språk, men det går inte att föra 
fakturorna mellan dessa på olika språk, för när det kommer in i system X så blir det 
automatiks på svenska. Det finns bara svenska att tillgå, men objektkoderna finns redan i 
andra språk. Det enda som är ligger kvar på skärmen är en listruta där man kan välja andra 
språk. Men den fyller ingen funktion. 

• Enklare att lägga rabatter på fakturan. 

• Man ser inte på fakturan vem som har varit ens mekaniker, detta fanns i det gamla 
systemet och skapade en relation till kunden. 

• Möjlighet att arbeta effektivare med att fylla i arbetsordem. I det gamla systemet var 
arbetsordern sidindelat vilket hade den fördelen att man på första sida hade orderhuvudet 
med alla kunduppgifter. På nästa sida (sidan 2) fanns alla poster uppradade och det blev 
enklare att fördela arbetesoperationer när man ser alla på en skärm. Man behövde inte 
skrolla sida för att se alla poster. Det måste man nu eftersom att allt ligger placerat på en 
halva skärmen sida. Efter orderhuvudet får man bara plats med en post service och byta 
torkarblad sedan är det fullt och du måste du köra med listpilama föra att se resten. Detta 
gör det svårare att dela upp och flytta poster när man inte ser hela sidan. De skulle 
underlätta med en stor skärm . Det har blivit bättre i takt med alla uppdateringar t.ex. nu 
står registreringsnumret och arbetsorder numret på samma ställen hela tiden, och flyttas 
inte runt. Det är oerhört lätt att ta fel på dessa nummer. 

• Det system som säljarna jobbare i uppdateras varje natt från Vägverket. Uppdateringen 
hämta då hem nya ägaruppgifter på en bil, men det uppdatering fungerar inte ännu mot 
System X vilket innebär att gamla ägare kan ligga som nuvarande ägare. Ibland dyker till 
och med tredje/fjärde ägaren bakåt i tiden upp som nuvarande ägare. Detta har gjort att 
man inte vågar lita på uppgifterna utan kontrollerar via CBR att det stämmer, vilket tar 
betalt med 2,50 kr för varje förfrågan man gör. (Enligt ekonomiansvarig låg kostnaden 
förra året på 400 000 kronor vissa förfrågningar är man ändå tvingade att, men kostnaden 
stiger när man inte kan lita på ägaruppgifterna) 
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KRITERIEBASERAD UTVÄRDERING MED 2 st VERKMÄSTARNA 

Kriterium 

Bedömningsgrund 

Kommentarer 

1. Enkelt kan förstås vad som 
kan göras med systemet 
(tydlig handlingsrepertoar) 

Delvis 

uppfyllt 

Inte lätt att vet var man lägger upp nya 
kunder, om man inte gör det dagligen. 

2. Kan ”sägas” det man vill 
genom systemet (tillgodose 
kommunikationsbehov) 

Delvis 

uppfyllt 

En bil som är inne igen på service, 
finns ingen plats för ny 
mätarinställning, utan man utnyttjar 
annan plast på arbetsorder, vilket 
medför man skriver lite varstans. 

3. Enkelt kan ta sig till önskad 
plats i systemet 
(lättnavigerbar) 

Delvis 

uppfyllt 

Ja, om man håller på med systemet 
dagligen. Menyerna är inte helt 
associerade med vad man ska göra. Det 
är svårt att komma ihåg vad vissa saker 
ligger när man inte gör det varje dag 
som t.ex. lägga upp nya kunder 

4. Förstå konsekvenserna av 
föreslagna och utförda 
handlingar 

(handlingstransparent ) 

Uppfyllt 

Det upplever verkmästarna att man gör 

5. Direkt se att det man 
försökt göra blev gjort 
(feedback) 

Delvis 

uppfyllt 

Det är svårt att se när vissa moment har 
tuggat klart. T ex när man plockar 
arbetsoperationer 

6. Enkelt få hjälp att veta vad 
som gjorts (tydligt och 
lättåtkomligt handlinsminne) 

Ej uppfyllt 

Man ser inte på faktura vem som har 
varit mekanikern. Det är lätt att tappa 
order rader, utan att man vet om det. 

Det är svårt att ta över arbetsorder från 
varandra och veta vad som sparat eller 
inte. 

7. Vet vem som ”sagt” vad 
(personifiering) 

Delvis 

Uppfyllt 

Det inloggade namnet dokumenteras. 
Och det är även lätt att ändra på 
arbetsordem, men den tids stämplade 
mekanikers namn borde också komma 
med på arbetsordem. 



Men ska man ändra namn måste man 
ändra på flera ställen. Detta sker inte 
med automatik att ändrar man på ett 
ställe så andras det på det andra stället 
också. 

8. Förstå använda begrepp 
(känd och begriplig 
vokabulär) 

Delvis 

Uppfyllt 

Att man lägger till en ny rad på 
fakturan med en knapp tryckning på 
metaforen ”mutter”. 

9. Förstå kommunikativt 
avsikt med olika meddelanden 

Uppfyllt 

Det är tydligt upplever verkmästarna 
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10. Få ett bra stöd för 
handlande i verksamheten 


Ej uppfyllt 


Besvärligt att skapa fakturor, Krångligt 
att se vem som varit mekaniker på en 
faktura. Allt tar nu för lång tid. 


Leveransansvarig 

Arbetsbeskrivning 

Den leveransansvarig tar hand om alla ordar från säljare, som innan har fått ordern godkänd 
av försäljningschefen. Säljaren producerar ordern i ett annat system som sedan förs över till 
System X, där leveransansvarig fortsätter arbeta med ordern. Denna order ska nu göras i 
ordning och vissa fakta ska kontrolleras, t.ex är det kredit ska detta kontrolleras hos 
finansiären, vilken leveransdag som gäller. Det är olika rutiner som gäller om det är en ny 
leverans eller en begagnad. Nu beställs bilen genom en gemensam samordnare mot fabriken 
och bekräftelse kommer via e-post. Man bevakar att ev. bonus som gäller med 
nybilsförsäljningen kommer in. Vidare ska bilen registreras på köparen till leveransdagen. 

Alltså ska den leveransansvarig se till att alla papper som rör bilen är klara den dagen kunden 
kommer in och hämtar bilen. Men det är sedan säljaren som överlämnar bilen till kunden. 
Leveransansvarig ansvarar föra att alla papper är i ordning och har ingen direkt kontakt med 
kunden. 

Vidare har leveransansvarig ansvar för att prisfiler hämtas hem och uppdateras i systemet. Det 
tar ca 3-4 minuter för systemet att göra, och det görs dagligen. 

Positivt 

• Nu kan en order innehålla flera bilar, vilket inte var möjligt förut. (Ett slags 
samlingsfaktura) Dessutom är det enklare när en faktura ska delas upp på fler intressenter. 

• Blir något fel i faktura angående finansiärer eller liknande, då är det mycket enkelt att 
ändra och göra en kreditfaktura och de uppskattas verkligen för det var krångligt i det 
gamla systemet. Vi extrema fall förut, fick detta göras om manuellt med en skrivmaskin. 

• Bra med olika sökbegrepp och då inte bara på registreringsnummer utan ordernummer och 
karossnummer från fabriken. 


Negativt 

• Leveransansvarig upplever att det är mer nu som måste fyllas i mot förut. Förut gick det 
att välja att viss information skulle ligga som standard, men all den informationen som nu 
ska visas på skärmen och applikationen som inte är maximerad utan täcker inte mer än ca 
en V* av skärmen (det hjälper inte att maximera) så är det väldigt ansträngande för ögonen. 
Framåt eftermiddag är det lätt att det blir fel när åttor blir till nollor. Det är också många 
formulär (fönster) som är öppet samtidigt och som man måste växlar i mellan när man 
arbetar. 

• Mycket mer papper skapas i det nya systemet. Kundkontrakt med fler finansiär inblandad 
produceras 16 sidor. Förut hade man förtyckta blanketter som kördes ut i radskrivare ut 2 
ex. men det var fyra papper i varje. Nu körs fyra papper ut som sedan kopieras i en vanlig 
kopiator, man trodde det skulle bli mindre papper att aktivera och att dessa pärmar skulle 
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bli mindre, men genom att kopiatorpappema är betydligt tjockare så tar det mycket mer 
plats att aktivera alla dessa kopior. 

• I den sista uppdateringen på systemet har vissa namnetiketter på formuläret tappats bort så 
som försäljningspris, årsmodell och produktgruppen har flyttat till ett annat ställe på 
skärmen. (Leveransansvarig vet ju på ett ungefär vad det har stått förut på etiketterna så 
det är bara att hoppas att kontrollkällan är den samma). 

• Visa fönster som öppnas för inmatning hamnar över annan information som man behöver 
se. (Det ser ganska rörigt ut på skärmen) Detta gör att man måste stänga ner och flytta 
vissa fönster för att se den information. Respondenten känner sig osäker på om man kan 
gör på något annat sätt för att slippa stänga ner fönstren. 

• Många konstiga felmeddelanden som man inte förstår. Exempelvis vid kompletteringar av 
uppgifter uppläggning begagnade bilar som redan finns i lager. Först kommer ett 
meddelande att bilen inte finns, men efter man tyckt ”OK” kommer nästa meddelande om 
att bilen finns. Ett annat felmeddelande av samma art är när, systemet talar om att bilen 
inte finns och man får frågan om man vill ”lägga upp bilen”. Men att svara ”OK” och 
trycka ”Enter”, ja då kommer ett nytt meddelande upp som talar om att bilen redan finns. 


Upplevda brister hos systemet 

• Att kopplingen mellan säljarens system och system X inte fungerar som tänkt, vilket 
medför att information mellan dessa system tappas. Till exempel om inbytesbilen inte har 
någon årsmodell, trots att det står på en utskrift från det andra systemet, (detta kan ibland 
skapa misstroende mellan de berörda, om man verkligen fyllt i eller inte)I det gamla 
systemet var detta moment helt manuellt det var papper och penna som gällde. Nu skulle 
denna funktion effektivisera denna process, men eftersom den levernsansvarige hela tiden 
måste gå igenom och kontrollera ordem så ser man ingen effekt ännu. Det bestämdes även 
att allt skulle vara skrivet med versaler, men det fungerar inte heller som det ska. 


KRITERIEBASERAD UTVÄRDERING MED LEVERANSANSVARIG 

Kriterium 

Bedömningsgrund 

Kommentarer 

1. Enkelt kan förstås vad som 
kan göras med systemet 
(tydlig handlingsrepertoar) 

Ej uppfyllt 

Inget är givet vad som ska fyllas i man 
måste veta innan. 

Man hade utryckt önskemål att vissa 
fält markerades i annan färg, och dessa 
skulle vara tvingade, men det har inte 
blivit da ännu. T.ex. fält som Årsmodell 
och mätarinställning etc. 

2. Kan ”sägas” det man vill 
genom systemet (tillgodose 
kommunikationsbehov) 

Uppfyllt 

Det upplever leveransansvarig att man 
kan. 

3. Enkelt kan ta sig till 
önskad plats i systemet 
(lättnavigerbar) 

Delvis 

Uppfyllt 

Det är mycket klickande för att ta sig 
någonstans. Har man inte gjort en ska 
på ett tag måste man sitta och grunna, 
hur komma ditt? 

4. Förstå konsekvenserna av 
föreslagna och utförda 

Uppfyllt 

Det upplever leveransansvarig att man 
får. 
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handlingar 

(handlingstransparent) 



5. Direkt se att det man 
försökt göra blev gjort 
(feedback) 

Ej uppfyllt 

Vissa moment får man ingen feedback 
och då blir respondenten osäker och 
dubbel kollar sig själv. T.ex. flytta en 
bil till en annan filial. När det är gjort 
får man ingen feedback, att bil 
verkligen är överflyttad. 

6. Enkelt få hjälp att veta vad 
som gjorts (tydligt och 
lättåtkomligt handlinsminne) 

Uppfyllt 

Man kan kontrollera i respektive 
historik. Begagnade, lager och 
fakturerat 

7. Veta vem som ”sagt” vad 
(personifiering) 

Delvis 

uppfyllt 

Det står inte vem som har gjort orden, 
men man kan se vem som är säljaren. 

8. Förstå använda begrepp 
(känd och begriplig 
vokabulär ) 

Delvis 

uppfyllt 

Visa nya ord som ”målpris” istället för 
försäljningspris. 

9. Förstå kommunikativt 
avsikt med olika 
meddelanden 

Ej 

uppfyllt 

Vissa meddelande som kommer när 
man hämtar information om bilen 
(Färgkoder och in inrednings detaljer) 
Först kommer ett meddelande om att 
den inte finns, man trycker ”okej” och 
efter det kommer ett nytt meddelande 
upp att den finns. 

Det kommer även upp konstiga 
meddelande som man inte vet varför de 
kommer. Man trodde alla uppdateringar 
på programvaran skulle ta skulle ta bort 
dessa. 

10. Få ett bra stöd för 
handlande i verksamheten 

Ej 

uppfyllt 

Det känns om det är mer som måste 
fyllas i än förut. Och med alla 
information och med en minskad yta på 
skärmen, blir det svårt att se allt och 
framåt eftermiddag när ögonen trötta är 
lätt att göra fel, t.ex. när åttorna blir 
nollor. 

Att vis information kunde läggas om 
standard och att man kunde ställa in hur 
mycket information som skulle visas. 
(Jämför med menyerna i Office där bar 
de kommandon som används visas). 

Det är många fält som man inte vet vad 
de är till för. Man fyller i de fält som 
man känner igen. 


20 




Bilaga 2 


Min bedömningsgrund för den målbaserade utvärderingen är följande eftersom jag inte ville 
använda mig av målgraf har jag valt att använda följande sätt: 

Kriterier bedöms efter: 

• Ändamålsenlighet - i vilken uträckning klarar respondenten uppgiften 

• Effektivitet - hur lång tid tar det att klara uppgiften 

Eftersom det inte mäts något så är det respondentens egen uppfattning som tolkas. 

• Tillfredsställelse - Här är det respondentens personliga tycke som registreras 

Uppfyllt = Jag anser att målet är uppfyllt när respondenten klara uppgiften. 

Delvis uppfyllt = Jag anser att målet är delvis uppfyllt om 50/50 är uppfyllt/uppfyllt och de ej 
uppfyllda är av sådan karaktär att det direkt påverkar de nödvändiga arbetsuppgifterna. 

Ej uppfyllt = Jag anser att det givna målet ej är uppfyllt, och är en självklarhet för att utföra 
arbetsuppgiften. 


När Respondenterna uppger att det inte har blivit enklare/snabbare eller tar längre tid, så 
referera den till det gamla systemet som fanns innan. Det var ett gammalt Textbaserat system 
som varit i drift i tjugo år. Se matrisen i avsnitt 8.4. _ 


Målbaserad utvärdering som sådant 

Mål 

KUNDMOTTAGARE 

Resultat 

Effektivisera och förenkla för Kundmottagare 

Ändamålsenlig 

Noggrannhet och fullständighet 
med vilken användarna uppnår 
givna mål 

Detta mål är Uppfyllt. Respondenten uppnår sina givna 
mål. 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet 
med vilken användaren uppnår 
givna mål 

Detta mål är Delvis uppfyllt men inte för de viktigaste 
arbetsuppgifterna. Det tar längre tid att utföra de 
viktigaste arbetsuppgifterna exempelvis ge kund rätt 
prisuppgift. 

De mål som är uppfyllda är: Skapa servicepaket, se 
historik, Enklare kreditfaktura 

Tillfredsställelse 

Frånvaro av obehag samt positiva 
attityder vid användning av en 
produkt 

Detta mål är - Ej uppfyllt. P.g.a. längre tid, mycket fel i 
informationen, krångligt att uppdatera information, Ej 
ge vettig prisuppgift till kunden. 
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Mål 

VERKMÄSTARE 

Resultat 

Effektivisera och förenkla för Verkstad 

Ändamålsenlig 

Noggrannhet och fullständighet 
med vilken användarna uppnår 
givna mål 

Detta mål är Uppfyllt. 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet 
med vilken användaren uppnår 
givna mål 

Detta mål är Ej uppfyllt , p.g.a. av att det är omständligt 
och tidsödande att göra fakturor. Krångligt med 
rabatter. 

Tillfredsställelse 

Frånvaro av obehag samt positiva 
attityder vid användning av en 
produkt 

Detta mål är Ej uppfyllt , p.g.a. exempelvis att 
kundmottagaren inte kommer åt tidstämplingen, därför 
hamnar faktureringen hos verkmästaren. 

Arbetsuppgiften tar längre tid och är krångligare, 
mycket redigering, lätt att tappa information, Det är 
svårt att ta över och hjälpa varandra med faktureringen, 
därför man inte kan se vad som har sparats eller inte etc. 
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Mål 

LEVERANS 

Resultat 

Effektivisera och förenkla för leveransmottagningen 

Ändamålsenlig 

Noggrannhet och fullständighet 
med vilken användarna uppnår 
givna mål 

Detta mål är Uppfyllt 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet 
med vilken användaren uppnår 
givna mål 

Detta är Ej uppfyllt, applikationen tappar information 
mellan säljare och leveransmottagare. Kräver kontroll. 
Vid uppdateringar tappar gränssnittet beskrivande 
information på inmatning. Viss texten är så liten att man 
kan förväxla nollor och åttor på skärmen. Gränssnittet 
har många överlappande fönster som måste flyttas för 
att se all information vilket innebär att de inte blir 
överskådligt. Dessutom kommer det obegripliga 
felmeddelanden upp. 

Tillfredsställelse 

Frånvaro av obehag samt positiva 
attityder vid användning av en 
produkt 

Det är delvis uppfyllt. Positivt att en order nu kan 
innehålla flera bilar och en slags samlingsfaktura kan 
skapas vid olika intressenter. Enklare skapa 
kreditfaktura, se historik. Bättre sökbegrepp. Men den 
som blev automatiserat fungerar inte. 
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Mål 

EKONOMI 

Resultat 

Effektivisera och förenkla framtagning av ekonomiska rapporter och annan information som 
ska ligga till grund för snabba beslut för VD, ledningsgruppen och andra personer 

Ändamålsenlig 

Noggrannhet och fullständighet 
med vilken användarna uppnår 
givna mål 

Detta mål är Uppfyllt trots att koppling mellan systemen 
inte fungerar (IT-system X och bokföringssystemet) 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet 
med vilken användaren uppnår 
givna mål 

Detta mål är Ej uppfyllt. Därför att avskrivningar på 
demonstrationsbilar bokför fel värde. Och siffror måste 
flyttas manuellt mellan systemen. Det är svårt att är 
svårt att spåra en faktura med flera köpare. Det saknas 
enstaka rapporter, men det är prioriterade ärende 

Tillfredsställelse 

Frånvaro av obehag samt positiva 
attityder vid användning av en 
produkt 

Detta mål är EJ uppfyllt. P.g.a. av ovanstående 


Mål 

LAGERHANTERING 

Resultat 

Effektivisera och förenkla för Lageransvarige 

Ändamålsenlig 

Noggrannhet och fullständighet 
med vilken användarna uppnår 
givna mål 

Detta mål är Uppfyllt. 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet 
med vilken användaren uppnår 
givna mål 

Detta mål är Delvis uppfyllts . Därför att en prisfråga 
inte kan skrivas ut direkt till kunden, utan måste först 
korrigeras. Rabattkoder får inte rum utan hämtas i ett 
infofönster. 

Verksamhets språk stämmer inte vid uppläggningen av 
ny artikel. 

Men det är enklare att skapa en kredit faktura, bättre 
sökbegrepp på artikelfrågor 

Tillfredsställelse 

Frånvaro av obehag samt positiva 
attityder vid användning av en 
produkt 

Detta mål är Ej uppfyllt. Det tar längre tid nu än med 
det gamla systemet. 
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Mål 

SERVICEMARKAND 

Resultat 

Effektivisera och förenkla för Servicemarkand 

Ändamålsenlig 

Noggrannhet och fullständighet med 
vilken användarna uppnår givna mål 

Detta mål är Uppfyllt. Med nya effektiva rapport har det 
blivit mycket enklare att följa upp försäljning inom 
verkstad och reservdelar. 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet med 
vilken användaren uppnår givna mål 

Detta är Uppfyllt 

Tillfredsställelse Frånvaro av obehag 
samt positiva attityder vid 
användning av en produkt 

Detta är Uppfyllt 
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Bilaga 2 


Mål egen mekaniker 

Resultat 

Effektivisera och förenkla för Egen mekaniker 

Ändamålsenlig 

Noggrannhet och fullständighet med 
vilken användarna uppnår givna mål 

Detta mål är Uppfyllt. 

Effektivitet 

Resursåtgång i förhållande till den 
noggrannhet och fullständighet med 
vilken användaren uppnår givna mål 

Detta är Ej uppfyllt, då mycket information måste fyllas 
i på enkla arbetsorder. Rabatter kan inte läggas in 
enkelt. 

Vid småarbeten som exempelvis byte av lampa. Är 
tidstämplingen inte effektiv utan bidrar till att det tar 
mycket längre tid att fakturera än att utföra jobbet. 

Därför att vissa delar om kunden går att uppdatera men 
inte all information. Då vissa uppgifter inte uppdateras 
fast systemet påstår det. Och ny arbetsorder måste tas 
fram för att all information ska vara rätt. 

Det kommer även in fel mätareinställning och datum 
kan visas fel 


Vid plockning av arbetsoperationer är det lätt att ledas 
fel vilket skapar stress då det är svårt att börja om. 

Det tar lång tid och är krångligt att jobba med 
rabatterna. 


Enklare skapa kreditfaktura, se historik 

Tillfredsställelse Frånvaro av obehag 
samt positiva attityder vid 
användning av en produkt 

Detta är Ej uppfyllt. Upplever att kontorsarbetet numera 
tar 75 % av arbetstiden. 
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